hi,
Ague Mill wrote (04 Jun 2012 15:15:15 GMT) :
> 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.
Our design page about it (contribute/design/memory_erasure) looks
clear enough to me; any idea what we can do to make this information
easier to find for the next person who needs it?
> 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.
Point taken. I now entirely agree this goal is valuable in itself.
Let's see what price we are willing to pay.
> 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.
I'd very much like this to be true, and this was my first thought too,
but I raised this issue when I realized things are, unfortunately,
slightly more complicated.
We ship packages from various everchanging sources, including
backports, sid, TTP's repository and custom .deb's. So in practice,
every time a package we fetch from one of these non-stable sources
updates its initscript, we risk some amount of breakage. Granted, we
don't fetch that many services from those sources, but we have been
and we will go on doing it. Granted, LSB headers don't change that
often. But still, the times when some maintenance / synchronization of
forked LSB headers may have to be done is not "new Debian release":
it is rather "constantly".
Also, the kind of breakage we're talking of is hard to notice and hard
to debug: boot/shutdown time is not the easiest to debug, it involves
parallel execution, possible race conditions, stuff run at a time when
it's too late to get a shell, etc.
So I'm unsure. I'm not veto'ing the idea at all, merely bringing all
facts on the table so that we can make a fully educated decision.
I'm slowly starting to seriously prefer the "patch initscripts' LSB
headers with chroot_local-patches/" approach. Although less elegant,
I think it would be more robust and cheap maintenance wise: we would
be told at (failed) *build* time when something has changed in the
context of the lines we're patching.
Thoughts, anyone?
> 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.
I think the live-boot initscript does a bit more work than the
emergency shutdown does, so the former needs to cache more files than
the latter. Given the live-boot one is only run at non-emergency
shutdown time, locking its dependencies in RAM during the whole Tails
session time would be a waste of memory. So, I'm not sure how we can
improve things in this area. But I've not tried hard.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
