I'm currently reading Advanced Programming in the Unix environment. In one of the exercises, it says:The only user-level daemon that isn't a session leader is the rsyslogd process. Explain why the syslogd daemon isn't a session leader.However, when I go to verify this myself, I see that on my system (Linux 4.4) it indeed is a session leader (because PID == SID):UID        PID  PPID  PGID   SID  CMDsyslog    1171     1  1171  1171  /usr/sbin/rsyslogd -nIs this a systemd thing? Some of the information in this book is a bit out of date now that everyone has jumped on the systemd bandwagon, whereas it talks mainly about classic System V init. Or perhaps that they've simply changed how it works? The book clearly wants to make a point of why it's different, so if anyone knows why historically it didn't used to be a session leader, and why it is now, that'd be excellent.
rsyslogd as a session leader
linux;process
EditI actually had a look at an old ubuntu 10.04 system that had rsyslogd 4.2.0 running.That one did not call setsid() at all (so inherited the sid from the process executing it) but instead did (here from strace output): 19391 open(/dev/tty, O_RDWR|O_LARGEFILE|O_CLOEXEC) = 0 19391 ioctl(0, TIOCNOTTY)               = 0To detach from the terminal.Looking at the source code it does that only when HAVE_SETSID is not set. Obviously Linux has setsid() and has had for decades, so there's something amiss.Now, looking more at the source, it's just the the build procedure never sets HAVE_SETSID as it doesn't check for the support of setsid() in the first place.The bug (a typo: setsid spelled setid in the autoconf file) was fixed in 2013 (first released in rsyslogd 7.5.3).(btw, see the TODO section about HP/UX in the old code which shows the authors had already realised there was something amiss (but didn't investigate it until much later)).Keeping original answer below, as one might find the information in there useful.A wild guess:If you're a session leader and open a tty device without the O_NOCTTY flag, then you become the controlling process of a terminal.That's why when trying to execute an application (that otherwise has not been designed to run as a daemon) so it runs as a daemon, it's recommended to do another fork after the setsid() before executing it to make sure the process doesn't inadvertently become a terminal controller if for some reason it opens a tty device.syslogd typically does open tty devices to send user messages, so it could be why your book says syslogd is not a session leader, describing the behaviour from syslogd implementations from a time where the O_NOCTTY flag didn't exist (though that flag has existed at least since the late 80s).The other approach is for syslogd to make sure that all the files it opens are opened with O_NOCTTY, which is probably what your rsyslogd (nothing to do with systemd) does.