<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 3:46 AM, Simon McVittie <span dir="ltr"><<a href="mailto:smcv@debian.org" target="_blank">smcv@debian.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Tue, 25 Mar 2014 at 22:41:32 -0007, Cameron Norman wrote:<br>
> It also uses the --nopidfile option to start dbus.<br>
<br>
Does the combination of "expect fork" and "there is no pid file" work<br>
properly? I'm somewhat surprised if it does; but if Upstart has some<br>
clever trick to follow processes even though they double-fork (like systemd's<br>
use of cgroups), then that's fine.<br></blockquote><div><br></div><div>Yes it works perfectly. Instead of using cgroups, Upstart uses ptrace to track forks and double forks, not PID files (it stops tracing it after the daemon is done forking).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> Please consider this for inclusion </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
[ snip  ]</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">More specifically, is anyone volunteering to maintain dbus' Upstart support<br>

by watching bug reports and "owning" any relevant bugs? I'm not going to<br>
test this configuration, and if it causes RC bugs that aren't addressed by an<br>
Upstart user, I'd be inclined to revert it rather than spending time on it.<br></blockquote><div><br></div><div>Reverting this if it causes problems is more than sensible. I am using and testing dbus with Upstart on my machine, and will try to fix any bugs that occur or are reported. That said, I do not think malfunction under the non-default init system or not sysv would be considered RC, or am I wrong?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> +stop on deconfiguring-networking<br>
<br>
This appears to have caused some rather upset bug reports in Ubuntu<br>
(<<a href="https://bugs.freedesktop.org/show_bug.cgi?id=76344" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=76344</a>>,<br>
<<a href="https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1072518" target="_blank">https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1072518</a>>)<br>
and I don't really want to have to field those bug reports in Debian too.<br>
<br>
I believe the rationale is that dbus-daemon is in /usr which could<br>
conceivably be NFS. Ubuntu's src:dbus packages install more of their<br>
contents to the root directory. I briefly tried to do similarly in Debian,<br>
but it caused regressions, so I had to revert it.<br></blockquote><div><br></div><div>unmounted-remote-filesystems seems to be what I want, but that hangs shutdown because it is emitted by an init script that is supposed to stop after dbus has stopped. I guess I will just have to `stop on runlevel [016]`.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
System service-activation will not work correctly until<br>
/usr/share/dbus-1/system-services becomes available, so moving the<br>
daemon to the rootfs probably doesn't help as much as you might think.<br>
<br>
> +start on local-filesystems </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Similarly, this doesn't necessarily provide /usr.</blockquote><div><br></div><div>`start on local-filesystems and mounted MOUNTPOINT=/usr` would not work because the mounted event is a hook, so it would lock mountall up. I guess I will just change it to filesystem for now and then deal with the strange mounting events later (I think I will write a mount bridge that hooks into the real kernel events instead of relying on mountall to emit them, but that is once school calms down :).</div><div><br></div><div>I have attached the revised version.</div><div><br></div><div>Thanks for your time,</div><div>-- </div><div>Cameron Norman</div>
</div></div></div>