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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
