I 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
19391 open("/dev/tty", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 0
19391 ioctl(0, TIOCNOTTY) = 0
To 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:
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