On Sun, Jun 03, 2012 at 02:17:53PM +0200, intrigeri wrote:
> Great work. Comments follow.
>
> > We now use this mechanism instead of having to call update-rc.d
> > manually, something quite error prone. Best example is that
> > 'ttdnsd' is actually requiring to be started after 'tor', but
> > that fact was previously overlooked.
>
> I obviously agree with the general idea, but FTR I think this example
> is plain wrong: this was not overlooked (see the 60-ttdnsd.sh NM
> dispatcher hook).
I have noticed the dispatcher hook, and I have indeed verified that the
'restart' call to the initscript would start the daemon if it was not
already done.
But still, ttdnsd is currently started at boot time, and at this point,
it is not in working conditions, as Tor is not started. This is the kind
of situation that insserv detects nicely.
> > +++ b/config/chroot_local-includes/etc/insserv/overrides/gdomap
> > @@ -0,0 +1,11 @@
> > +### BEGIN INIT INFO
> > +# Provides: gdomap
> > +# Required-Start: $remote_fs $syslog
> > +# Required-Stop: $remote_fs $syslog
> > +# Default-Start:
> > +# Default-Stop: 0 1 6 2 3 4 5
> > +# Short-Description: Start the GNUstep distributed object mapper
> > +### END INIT INFO
>
> Do we really need to duplicate that much of the header,
> instead of just overriding the field we want to change?
Unfortunately, yes.
> If insserv forces us to do so: I agree such overrides are better than
> manually patching initscripts or using update-rc.d when we previously
> did so, but for other cases (I mean, initscripts we did not hack in
> any way previously), I seriously doubt the added maintenance cost is
> worth a quicker non-emergency shutdown.
>
> > Tails shutdown sequence should be as fast as possible.
>
> This is probably nitpicking, but such an unbacked assertion means
> little to me, especially since we already have a totally separate
> emergency shutdown procedure.
It finally hit me and I finally found that emergency procedure in
`/usr/local/sbin/udev-watchdog-wrapper`. It was not that obvious to me
before that.
With persistence, I feel less inclined to just pull an USB stick to shut
down Tails; loosing data is not something I like on a daily basis. But
after pressing the top right red button, I don't like to wait before
pulling it out either. In my eyes this is enough to try to reduce
time spent in the shutdown sequence.
I don't feel those headers are that much work. It looks to me as a work
that has to be done once for each Debian release. But I understand your
concerns.
In the current incarnation of `feature/shutdown_cleanup`, there also is
a significant pause in the 'live' script. Some of it because it reads
files it will need after ejecting the system medium. Something we
already do with `memlockd`… This is worth some more investigation as
well.
--
Ague
