[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: Re: [PATCH] getty: remove the statement of pid and sid comparison
From: Sam Liddicott <sam () liddicott ! com>
Date: 2014-05-12 6:20:19
Message-ID: CAOj-5WDP4Nzryx6xYKNcwuheoAn1JStatDPdXAhEdNeMGDo8fA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Maybe "&& true" is better than "; true" so that the correct exit code will
also be returned.
Sam
On 10 May 2014 23:19, "Denys Vlasenko" <vda.linux@googlemail.com> wrote:
> 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@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@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@p1022ds:~#
> >
> > Fix following runtime issue of getty:
> > root@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.
> _______________________________________________
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>
[Attachment #5 (text/html)]
<p dir="ltr">Maybe "&& true" is better than "; true" so \
that the correct exit code will also be returned.</p> <p dir="ltr">Sam</p>
<div class="gmail_quote">On 10 May 2014 23:19, "Denys Vlasenko" <<a \
href="mailto:vda.linux@googlemail.com">vda.linux@googlemail.com</a>> wrote:<br \
type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> On Saturday 10 May 2014 04:17, \
Zhenhua Luo wrote:<br> > when setsid failed, the pid and sid doesn't equal, so \
remove following<br> > condition statement.<br>
> if (getsid(0) != pid)<br>
><br>
> Following is the content and output of test program.<br>
> root@p1022ds:~# cat sid_test.c<br>
><br>
> int main() {<br>
> pid_t pid;<br>
><br>
> pid = setsid();<br>
> if (pid < 0) {<br>
> int fd;<br>
> pid = getpid();<br>
> if (getsid(0) != pid) {<br>
> printf("setsid failed: pid %d ppid %d sid %d pgid \
%d",<br> > pid, getppid(),<br>
> getsid(0), getpgid(0));<br>
> }<br>
> }<br>
> }<br>
><br>
> root@p1022ds:~# ./sid_test<br>
> setsid failed: pid 2452 ppid 2408 sid 2408 pgid 2452<br>
<br>
It fails because it is a process group leader.<br>
Its pid is a process group id.<br>
<br>
If it would succeed, it should create new session<br>
*and new process group* with the pgid == pid.<br>
But it's not possible to have two process groups with the same pgid.<br>
What to happen to other members of existing PG?<br>
<br>
Of course, this wouldn't be a problem if this PG has only one<br>
member - this process.<br>
But kernel doesn't check for this case, it just fails<br>
setsid() if process is a process group leader.<br>
<br>
<br>
> root@p1022ds:~#<br>
><br>
> Fix following runtime issue of getty:<br>
> root@p1025:~# getty 115200 /dev/ttyQE1<br>
> getty: setsid: Operation not permitted<br>
<br>
I'm not sure about this.<br>
<br>
The programs called from getty (e.g. login) expect to be session leaders.<br>
Giving them that *sometimes* can lead to puzzling behavior<br>
when something "sometimes works".<br>
<br>
I feel that failing outright is better.<br>
<br>
Try:<br>
<br>
# sh -c 'getty 115200 /dev/ttyQE1; true'<br>
<br>
(the "...; true" part is to prevent "last command can be exec-ed" \
optimization<br> done by some shells)<br>
<br>
This way, getty isn't a process group leader, and setsid() works.<br>
_______________________________________________<br>
busybox mailing list<br>
<a href="mailto:busybox@busybox.net">busybox@busybox.net</a><br>
<a href="http://lists.busybox.net/mailman/listinfo/busybox" \
target="_blank">http://lists.busybox.net/mailman/listinfo/busybox</a><br> \
</blockquote></div>
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic