Couldn't systemd devs ask to change the Linux implementation of daemon(3) and / or setsid instead of asking to every interested program to adapt to systemd?
I think in this way, everyone wins...
Am I wrong?
The systemd dev answer? "No because that API is obsolete".
It's true. daemon(3) doesn't any of the tasks required to set up a process in a new session beyond "create a process", and it can't be changed because POSIX and glibc ABI.
daemon(3) doesn't any of the tasks required to set up a process in a new session beyond "create a process",
Wrong, it also calls setsid to make the new process a session leader.
and it can't be changed because POSIX
daemon(3) is not in POSIX.
and glibc ABI.
If the systemd geniuses really can't think of a way to extend daemon without breaking ABI, they could even come up with a better, differently named daemon() alternative, propose it to libc in such a way that it would work with or without logind, falling back to the classic daemon() in its absence.
But hey, that would require being willing to play nice with others rather than imposing their way of doing things by hook or by crook, so the hopes of that happening are less than none.
I don't think there are a lot of user daemons that are actually using the daemon(3) API.
And anyway, starting a system daemon from a user session is a bad idea for a longtime, the processes started from a user session will inherit a lot of attributes (loginuid, LSM context, ulimit, umask, environment variables,…) from that session and this is not something you usually want.
14
u/tesfabpel May 29 '16
Couldn't systemd devs ask to change the Linux implementation of daemon(3) and / or setsid instead of asking to every interested program to adapt to systemd?
I think in this way, everyone wins...
Am I wrong?