Re: [Tails-dev] memlockd stopped too soon

Delete this message

Reply to this message
Author: Ague Mill
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] memlockd stopped too soon
On Fri, Jun 01, 2012 at 06:37:09PM +0200, intrigeri wrote:
> Ague Mill wrote (01 Jun 2012 14:38:06 GMT) :
> > Please have a look at the `bugfix/dont_stop_memlockd` branch. It is
> > a candidate for 0.12.
>
> Looks great!
>
> A few minor comments, that may be related, and may be not, you tell
> me:
>
> * The commit message reads "In addition, we fix initscript ordering
> related to tails-sdmem-on-media-removal." -- why and how?
> * Why are the tails-reconfigure-kexec and tails-reconfigure-memlockd
> initscripts moved to by-hand numbering?
> * It's not clear why the tails-sdmem-on-media-removal start order
> changes. Both, given nothing in the commit message talks of
> initscripts startup.


They are all related. Please note that this discussion is actually quite
moot because our boot sequence is managed with insserv: it is the LSB
headers in the initscript that actually matters.

But anyhow, the order written in 52-update-rc.d was the following:

17 tails-detect-virtualization
20 tails-reconfigure-kexec
20 tails-reconfigure-memlockd
22 memlockd
23 tails-sdmem-on-media-removal

'defaults' that was currently specified for both is equivalent to 20.
'tails-reconfigure-memlockd' calls '/etc/init.d/memlockd restart'. This
implies that memlockd is already started, as described in the
Required-Start field of the LSB header.

The new sequence is :

17 tails-detect-virtualization
22 memlockd
23 tails-reconfigure-kexec
23 tails-reconfigure-memlockd
24 tails-sdmem-on-media-removal

I kept the number for memlockd and moved the rest after it.

But that was not enough to really get that order: as said erliar, we use
insserv. So `tails-sdmem-on-media-removal` now has a `Required-Start`
dependency on both `tails-reconfigure-kexec` and
`tails-reconfigure-memlockd` instead of `memlockd`.

This is really a tiny issue, but it felt more correct that way.

> To end with, I think the explanations found in the commit message
> would be worth pushing to the memory wipe design doc. I think this is
> the kind of knowledge we really don't want to have to dig in the Git
> history when we need it.


I just pushed an extra commit with an update to the design doc.

> > +       rm -f /lib/init/rw/sendsigs.omit.d/memlockd
> > +       ln -s /var/run/memlockd.pid /lib/init/rw/sendsigs.omit.d/memlockd

>
> Why not using "ln -sf" instead?


To be safe, it would have to be 'ln -nsf'. What I did is actually to
paste the commands that were used in the 'portmap' and 'rsyslog'
initscripts without much thoughts. You forgetting the 'n' flag makes me
think that it might not have been the worst approach. ;)

--
Ague