[PATCH] getty: remove the statement of pid and sid comparison

[Denys Vlasenko]

On Saturday 10 May 2014 04:17, Zhenhua Luo wrote:
> when setsid failed, the pid and sid doesn't equal, so remove following
> condition statement.
>     if (getsid(0) != pid)
> 
> Following is the content and output of test program.
> root at p1022ds:~# cat sid_test.c
> 
> int main() {
>     pid_t pid;
> 
>     pid = setsid();
>     if (pid < 0) {
>         int fd;
>         pid = getpid();
>         if (getsid(0) != pid) {
>              printf("setsid failed: pid %d ppid %d sid %d pgid %d",
>               pid, getppid(),
>               getsid(0), getpgid(0));
>         }
>     }
> }
> 
> root at p1022ds:~# ./sid_test
> setsid failed: pid 2452 ppid 2408 sid 2408 pgid 2452

It fails because it is a process group leader.
Its pid is a process group id.

If it would succeed, it should create new session
*and new process group* with the pgid == pid.
But it's not possible to have two process groups with the same pgid.
What to happen to other members of existing PG?

Of course, this wouldn't be a problem if this PG has only one
member - this process.
But kernel doesn't check for this case, it just fails
setsid() if process is a process group leader.


> root at p1022ds:~#
> 
> Fix following runtime issue of getty:
> root at p1025:~# getty 115200 /dev/ttyQE1
> getty: setsid: Operation not permitted

I'm not sure about this.

The programs called from getty (e.g. login) expect to be session leaders.
Giving them that *sometimes* can lead to puzzling behavior
when something "sometimes works".

I feel that failing outright is better.

Try:

# sh -c 'getty 115200 /dev/ttyQE1; true'

(the "...; true" part is to prevent "last command can be exec-ed" optimization
done by some shells)

This way, getty isn't a process group leader, and setsid() works.