On Thu, Apr 13, 2006 at 01:07:59AM +0200, Jonas Smedegaard wrote:
> On Thu, 13 Apr 2006 11:03:24 +1000 Anand Kumria wrote:
>
> > On Wed, Apr 12, 2006 at 12:41:28PM +0200, Jonas Smedegaard wrote:
>
> > > I interpret policy as mandating daemons to always use invoke-rc.d
> > > and thus respect policy.d - but I am unsure about this
> > > interpretation, so lowering severity. Please raise it if you agree
> > > with my interpretation.
> >
> > I don't actually see a section in the online policy which talks about
> > policy.d -- however it has been a long time since I've read it.
> > Pointers welcome.
>
> §9.3.2:
>
> > Packages that include daemons for system services should place
> > scripts in `/etc/init.d' to start or stop services at boot time or
> > during a change of runlevel.
>
> §9.3.3:
>
> > Maintainers should use the abstraction layer provided by
> > the `update-rc.d' and `invoke-rc.d' programs to deal with initscripts
> > in their packages' scripts such as `postinst', `prerm' and `postrm'.
>
> Policy.d is implicit to those mandatory (for "system daemons", which I
> suspect your daemon is too) rc.d scripts. Read the manpage of
> invoke-rd.d, section "INIT SCRIPT POLICY" for details on policy.d.
Right, so your assumption here is that zeroconf is a system-level
daemon. This isn't the case, although I'm happy to talk to upstream
about changing it to be one. zeroconf is a per-device daemon.
> > There are a few options:
> >
> > - modify /etc/default/zeroconf and uncomment DISABLE
>
> Seems impossible to do conditionally only when chroot'ing, without
> interfering with concurrent NFS access to same rootfs.
Huh? I'm not sure I understand.
> > - determine why the chroot thinks that a network interface is
> > operational and fix that
>
> A network interface _is_ operational as the chroot is borrowing it from
> the host system. It is the assumption in postinst that starting
> additional daemons directly is ok, which is wrong imho.
Okay but does the chroot have control over the interface? If not then
having /etc/network/ifstate (really /etc/network/run/ifstate) in the
chroot is decidely odd.
> > - work out the reason that zeroconf is being brought into the
> > chroot and stop that from occuring
>
> Well, that was done on purpose - as I want the daemon in other
> situations than when initially chroot'ed, as explained above :-)
Okay, basically you want:
- when in chroot don't run zeroconf
- otherwise let zeroconf run
> > I think I've listed the options from easiest to hardest. I can't
> > think of a way of having zeroconf run via /etc/init.d/ and properly
> > operating (it is supposed to survive ifup/ifdown cycles).
> >
> > Your thoughts would be appreciated.
>
> How about simply avoid invoking the daemon in postinst. Or wrap it in a
> debconf question offering to start zeroconf immediately (with "no" as
> default!), at the same time informing that alternatively interfaces
> needs to be restarted before zeroconf is active.
>
> Adding hooks to ifupdown is ok, but assuming that interfaces already up
> was done using ifupdown (and can thus unconditionally be messed with
> directly) is wrong imho.
But the interface *is* up. /etc/network/ifstate tells me it is and,
moreover, that it was brought up via the ifup mechanism. For Xen/UML
systems the interfaces are up but that doesn't occur via ifup so
zeroconf never runs (for example).
Going back to your original report, the problem is /dev is kept mounted
by zeroconf -- I can modify it (trivialy) to close stdin, stdout and
stderr so that it doesn't keep /dev mounted. Which would seem to solve
your issue if I'm not mistaken?
Cheers,
Anand
--
`When any government, or any church for that matter, undertakes to say to
its subjects, "This you may not read, this you must not see, this you are
forbidden to know," the end result is tyranny and oppression no matter how
holy the motives' -- Robert A Heinlein, "If this goes on --"
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
