Does POSIX indeed require programs to abort (vulgo: fail) in order to avoid executing a NOOP?
Specifically:
According to setpgid(2) such call can fail with [EPERM] if the process is session leader. According to Wikipedia, POSIX requires a session leader to not being allowed to setpgid().
Background:
A session is the collection of processes that belong to a login, that is, to a terminal (visible in column TT of
A process group is a collection of processes that will collectively react on signals, e.g., to ^C pressed. (If you execute a pipe and press ^C, all the processes in the pipe shall terminate, and that is achieved per process groups). A process group always belongs entirely to a session.
Now, if I understand that code snippet correctly, the running process determines it's own PID with getpid(), and then joins the process group made up by itself, that means, it declares itself the leader of a new process group. (This makes sense for a process that wants to run independently in the background, that is, a daemon.)
But then, if this process gets properly deamonized beforehand, by starting it with daemon(8), then it is already session leader of a new session (that is, disconnected from the terminal; visible by the empty TT field in
So, either I understand something completely wrong here, or, otherwise, it is just wrong, and then why the heck do we keep such code in our base system?? (I thought we love daemons)
Specifically:
Code:
pgrp = getpid();
if(setpgid(0, pgrp) < 0)
err(1, "setpgid");According to setpgid(2) such call can fail with [EPERM] if the process is session leader. According to Wikipedia, POSIX requires a session leader to not being allowed to setpgid().
Background:
A session is the collection of processes that belong to a login, that is, to a terminal (visible in column TT of
ps axl).A process group is a collection of processes that will collectively react on signals, e.g., to ^C pressed. (If you execute a pipe and press ^C, all the processes in the pipe shall terminate, and that is achieved per process groups). A process group always belongs entirely to a session.
Now, if I understand that code snippet correctly, the running process determines it's own PID with getpid(), and then joins the process group made up by itself, that means, it declares itself the leader of a new process group. (This makes sense for a process that wants to run independently in the background, that is, a daemon.)
But then, if this process gets properly deamonized beforehand, by starting it with daemon(8), then it is already session leader of a new session (that is, disconnected from the terminal; visible by the empty TT field in
ps axl) and, obviousely, group leader, and the above code becomes a NOOP. But nevertheless it then fails, because a session leader is not allowed to execute setpgid() on itself! Therefore, the process will abort right here at the start, and cannot operate.So, either I understand something completely wrong here, or, otherwise, it is just wrong, and then why the heck do we keep such code in our base system?? (I thought we love daemons)