On Tue, Jan 6, 2015 at 4:02 AM, Laurent Bercot
<ska-supervision_at_skarnet.org> wrote:
> On 06/01/2015 09:00, Colin Booth wrote:
>
>> 1. Depending on your initramfs and your on-disk layout you can skip
>> mounting proc and sys. I know this is the case with Debian, probably
>> true elsewhere as well.
>
>
> It all depends on the assumptions that init-stage2 makes, but yes,
> now that you're mentioning it, mounting /proc and /sys may be
> delayed, as long as none of the very early services need them.
> Make sure the login process and interactive root shell do not need
> them either, because if init-stage2 fails very early, being able to
> log in will make debugging/recovery a lot easier.
>
In Debian's case, initramfs had already loaded /proc and /sys so
trying to mount them again was causing things to fail.
>
>> 2. If you aren't starting udev until init-stage2, you'll need to
>> manually mknod null and console devices before the "Reopen
>> stdin/stdout/stderr" comment.
>
>
> That only applies to people who want a static /dev. Most people
> will run some flavour of udev, and will probably want to keep the
> devtmpfs mounted on /dev, in which case the kernel exports
> /dev/null and /dev/console itself. (Probably with the wrong rights,
> but they're functional enough to get by until udev runs.)
>
Hm, true. I guess that note is only if you are running with /dev as a
symlink to /mnt/tmpfs/dev since you get a tmpfs in that case. This is
what the init-stage1 script assumes. So, either make the nodes, run
udev as part of init-stage1, or use devtmpfs. I suggest the last :)
>
>> 3. You'll need to either symlink /tmp into your tmpfs, mount a tmpfs
>> on /tmp as part of init-stage1, or remount / to rw before s6-svscan is
>> loaded. Otherwise the catch-all logger won't be able to do its thing
>> as written. Same deal with /service, though that one is documented and
>> expected.
>
>
> Actually, neither of those 3 things are needed for /tmp. :)
> What *is* needed is a writable-by-root-only directory, to store the
> information init needs:
> - The scan directory, which must be rw
> - rw places to store the supervise/ and event/ subdirectories of
> the service directories, or a copy of the service directories
> themselves
> - a rw place for the catch-all logger to run
>
> /tmp is not ideal for this, for several reasons. One of which is
> as soon as stage 2 begins and user stuff runs on the system, creating
> files in /tmp isn't absolutely secure anymore, because filenames can
> be predicted and DoSsed. Another reason is conceptual: the information
> we need to store is not exactly temporary, it's not the throwaway
> stuff you'd expect to see in /tmp - on the contrary, it's vital to the
> system. So it's very unsightly to put it in /tmp.
>
Makes total sense. In that case though, s6-svscan-log/run should
probably be updated in the examples so that it doesn't try to use /tmp
since any /tmp/uncaught-logs symlink will be unavailable if a tmpfs
does get mounted or something cleans up /tmp. In the first case you're
doing more work in init-stage1 than necessary, in the second you're
back to having a rw root (if even for a second).
>
> That is why I'm saying that s6 needs a tmpfs, distinct from /tmp,
> made in stage 1. Having a "private" tmpfs allows init to store the
> scan directory, the copies of service directories, and the catch-all
> logger directory, without impacting the rest of the system.
> Since that tmpfs is needed anyway, /tmp might as well be a symlink
> to a public (mode 1777) subdirectory of it: it makes /proc/mounts
> cleaner. But it's not a requirement, and /tmp may be mounted as a
> separate tmpfs at some point in stage 2.
>
>
> If you are reckless, totally insensitive to gracefulness, and you
> absolutely cannot deal with creating a tmpfs just for the sake of s6,
> you may try to use a subdirectory of the devtmpfs in /dev as an
> early root-only read-write place.
> You will now forget I suggested that. *flash*
>
That. Wow. That's amazingly bad.
>
>> 4. If you don't want to have your dev mount in /mnt/tmpfs/dev (mostly
>> to keep ps output non-ugly and to kind-of stick to the FHS)
>
>
> Eh, the FHS doesn't say that /dev should be a real directory. It can
> be a symlink all right. I checked. :P
> Most Linux people will use udev, though, and for them /dev will be a
> devtmpfs: a real directory, and a mountpoint.
>
Mostly it's to keep the output of ps non-mangled when you ssh in. A
tty of pts/XX doesn't mess up the column output, a tty of
/mnt/tmpfs/dev/pts/XX definitely does. That said, I'm a bit surprised
that the FHS doesn't care beyond needing the name present.
>
> The order in which init-stage2 starts services and interleaves them
> with one-shot commands should mirror your dependency graph. This is
> where a dependency management system would come in handy; I plan to
> work on a program that takes a dependency graph as its input (format
> TBD) and outputs a suitable init-stage2 script.
>
It would. In my case though, I knew the services that I needed running
and manually did the dependency ordering from the existing debian init
scripts.
>
>> Everything between the fdclose line and repoening stdin is super
>> fragile, and since we've unmounted /dev, it's impossible to boot
>> half-way and then start a shell to find out what exactly went wrong.
>
>
> I will definitely be working on a s6-init package to automate all
> this and make sure the fragile part is as brief as possible. The
> really risky stuff is replacing /dev/console under init's nose; for
> udev users, this won't even happen, so stage 1 will be practically
> safe.
>
>
> Thanks for your comments!
>
> --
> Laurent
>
You're welcome. I think I mentioned this, but most of my gotchas above
are for people (like myself) who are doing an init swap on a computer
that's running a distribution and don't want to trash things to the
point where you need to reboot into a recovery shell to put things
back the way your other init expects. A few other things, such as the
/tmp issue, have more to do with unspoken assumptions made in the
examples than they do with any actual failing.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Tue Jan 06 2015 - 17:29:24 UTC