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):

syslog    1171     1  1171  1171  /usr/sbin/rsyslogd -n

Is 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.

migrated from stackoverflow.com Dec 29 '16 at 10:33

This question came from our site for professional and enthusiast programmers.

  • PS. I decided to post this here instead of Unix&Linux SE because it is still motivated by programming (forks and the like), as opposed to system administration. – Daniel Porteous Dec 22 '16 at 4:48
  • I find it strange that that book has such a question. The reason why rsyslogd was not a session leader was because of a bug (typo in the code), so either the book authors knew of that bug (and then they should have notified the rsyslogd maintainers, not release a book asking readers to find the bug as an exercise), or they don't know what they're talking about. – Stéphane Chazelas Dec 23 '16 at 11:10
  • Yeah that is really strange, it's a shame they didn't include an answer (they do for some questions). Accepting your answer below, really comprehensive, that's some serious digging. Thanks! – Daniel Porteous Dec 23 '16 at 11:41


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 strace output):

 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: 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.

  • Unfortunately the book does indeed talk about the O_NOCTTY flag, it was published in 2013, and talks about the method through which other processes become session leaders with controlling terminals. It then proceeds to ask specifically about rsyslogd as an exception, so I feel it might be something else. – Daniel Porteous Dec 23 '16 at 2:39
  • @Daniel, see edit. That was because of a bug that has later been fixed. – Stéphane Chazelas Dec 23 '16 at 11:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.