Re: s6-devd, stdin stdout
On 07/03/2015 18:37, Olivier Brunel wrote: Hi, I have a question regarding s6-devd: why does it set its stdin stdout to /dev/null on start? Hi Olivier, The original purpose of s6-devd was actually to emulate the behaviour of /proc/sys/kernel/hotplug, using the netlink to serialize calls instead of having them all started in parallel. A helper program called by /proc/sys/kernel/hotplug would start with stdin and stdout - and even stderr - set to /dev/null. That's where the redirection in s6-devd comes from. Changing that behaviour means that a program that's used with s6-devd is not guaranteed to be able to use as a /proc/sys/kernel/hotplug helper if it performs I/O. But that's probably not important, so I can remove the stdout redirection, it shouldn't be a problem - stderr is already non-redirected anyway. The stdin redirection, though, should stay: you don't want a hotplug helper to depend on a state defined by streamed userland input. Specifically, the doc for s6-setuidgid says: If account contains a colon, it is interpreted as uid:gid, else it is interpreted as a username and looked up by name in the account database. This doesn't seem to be true (anymore?). Gah. I totally forgot about that change when rewriting s6-setuidgid. Now that s6-applyuidgid exists, I really want to get rid of that quirkiness... but it's my fault, so rather than removing the bit of documentation, I'll reimplement the feature. Duh. -- Laurent
s6-devd, stdin stdout
Hi,
I have a question regarding s6-devd: why does it set its stdin stdout
to /dev/null on start?
This seems non-obvious to me, and isn't documented. I'm specifically
wondering about stdout, since it means all the children/helpers launched
will also have their stdout be /dev/null, so anything they printed
actually gets lost, whereas I was expecting to find it logged, since I
set s6-devd to have its std{out,err} sent to its s6-log.
Unless there's a reason I'm missing, maybe those forced redirections
should be removed?
Also, completely unrelated, but I noticed a bug in the doc for
s6-setuidgid: As it turns out, this only calls s6-envuidgid
s6-applyuidgid, but - according to the doc - there's a difference in
behavior. Specifically, the doc for s6-setuidgid says:
If account contains a colon, it is interpreted as uid:gid, else it is
interpreted as a username and looked up by name in the account database.
This doesn't seem to be true (anymore?).
Cheers,
-j
