[Pkg-utopia-maintainers] Bug#712167: dbus: add upstart init support

Cameron Norman camerontnorman at gmail.com
Wed Mar 26 23:15:17 UTC 2014


On Wed, Mar 26, 2014 at 3:46 AM, Simon McVittie <smcv at debian.org> wrote:
> On Tue, 25 Mar 2014 at 22:41:32 -0007, Cameron Norman wrote:
> > It also uses the --nopidfile option to start dbus.
> 
> Does the combination of "expect fork" and "there is no pid file" work
> properly? I'm somewhat surprised if it does; but if Upstart has some
> clever trick to follow processes even though they double-fork (like 
> systemd's
> use of cgroups), then that's fine.
> 

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).

> > Please consider this for inclusion 
‘2’
> More specifically, is anyone volunteering to maintain dbus' Upstart 
> support
> by watching bug reports and "owning" any relevant bugs? I'm not going 
> to
> test this configuration, and if it causes RC bugs that aren't 
> addressed by an
> Upstart user, I'd be inclined to revert it rather than spending time 
> on it.
> 

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?
 
> > +stop on deconfiguring-networking
> 
> This appears to have caused some rather upset bug reports in Ubuntu
> (<https://bugs.freedesktop.org/show_bug.cgi?id=76344>,
> <https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1072518>)
> and I don't really want to have to field those bug reports in Debian 
> too.
> 
> I believe the rationale is that dbus-daemon is in /usr which could
> conceivably be NFS. Ubuntu's src:dbus packages install more of their
> contents to the root directory. I briefly tried to do similarly in 
> Debian,
> but it caused regressions, so I had to revert it.
> 

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]`.
 
> System service-activation will not work correctly until
> /usr/share/dbus-1/system-services becomes available, so moving the
> daemon to the rootfs probably doesn't help as much as you might think.
> 
> > +start on local-filesystems 
‘6’

`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 :).

I have attached the revised version.

Thanks for your time,
-- 
Cameron Norman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20140326/64f2eaa1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbus-upstart-4.deb.diff
Type: text/x-patch
Size: 3271 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20140326/64f2eaa1/attachment.bin>


More information about the Pkg-utopia-maintainers mailing list