SIGHUP on pty closure

[Marco atzeri]

looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.

Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?



------------- extract from subshell.c --------------
/* Attach all our standard file descriptors to the pty */

/* This is done just before the fork, because stderr must still */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them. */

dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);

close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
case... */
/* Close master side of pty. This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear. */
close (subshell_pty);

/* Execute the subshell at last */

switch (subshell_type)
{
case BASH:
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
----------------------------------------------------------

[Marco atzeri]

Post by Marco atzeri
looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.
Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?
------------- extract from subshell.c --------------
/* Attach all our standard file descriptors to the pty */
/* This is done just before the fork, because stderr must still */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them. */
dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);
close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
case... */
/* Close master side of pty. This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear. */
close (subshell_pty);
/* Execute the subshell at last */
switch (subshell_type)
{
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
----------------------------------------------------------

It seems that mc is correct in the expectation.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html

"If fildes refers to the master side of a pseudo-terminal, and this is
the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is the
controlling terminal. It is unspecified whether closing the master side
of the pseudo-terminal flushes all queued input and output."


I don't find such implementation on cygwin

fhandler_pty_master::close ()

Am I looking in the wrong place ?

Regards
Marco

[Corinna Vinschen]

Post by Marco atzeri
It seems that mc is correct in the expectation.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
"If fildes refers to the master side of a pseudo-terminal, and this
is the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is
the controlling terminal. It is unspecified whether closing the
master side of the pseudo-terminal flushes all queued input and
output."
I don't find such implementation on cygwin
fhandler_pty_master::close ()
Am I looking in the wrong place ?

No, I don't think so. I'm not fluent with mc. How can I reproduce
the issue?


Corinna

[Marco atzeri]

Post by Corinna Vinschen

Post by Marco atzeri
It seems that mc is correct in the expectation.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
"If fildes refers to the master side of a pseudo-terminal, and this
is the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is
the controlling terminal. It is unspecified whether closing the
master side of the pseudo-terminal flushes all queued input and
output."
I don't find such implementation on cygwin
fhandler_pty_master::close ()
Am I looking in the wrong place ?

No, I don't think so. I'm not fluent with mc. How can I reproduce
the issue?
Corinna

$ mc -U (to run mc with subshell)

pres CTRL-O (to swith on subshell)

$ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
1112 1 1112 1112 ? 1006 13:42:30 /usr/bin/mintty
556 1112 556 5860 3 1006 13:42:30 /usr/bin/bash
5048 556 5048 2720 3 1006 13:43:00 /usr/bin/mc
2820 5048 2820 2064 0 1006 13:43:00 /usr/bin/bash
460 2820 460 5980 0 1006 13:43:04 /usr/bin/ps


press CTRL-O (to return on mc)

F10 (to exit from mc)

the subshell remains open

$ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
1112 1 1112 1112 ? 1006 13:42:30 /usr/bin/mintty
556 1112 556 5860 3 1006 13:42:30 /usr/bin/bash
I 2820 1 2820 2064 0 1006 13:43:00 /usr/bin/bash
2968 556 2968 5096 3 1006 13:43:42 /usr/bin/ps

sending the SIGHUP
$ kill -SIGHUP 2820

$ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
1112 1 1112 1112 ? 1006 13:42:30 /usr/bin/mintty
556 1112 556 5860 3 1006 13:42:30 /usr/bin/bash
5344 556 5344 4804 3 1006 13:44:06 /usr/bin/ps

the subshell closes.

Regards
Marco

[Christopher Faylor]

Post by Marco atzeri

Post by Corinna Vinschen

Post by Marco atzeri
It seems that mc is correct in the expectation.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
"If fildes refers to the master side of a pseudo-terminal, and this
is the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is
the controlling terminal. It is unspecified whether closing the
master side of the pseudo-terminal flushes all queued input and
output."
I don't find such implementation on cygwin
fhandler_pty_master::close ()
Am I looking in the wrong place ?

No, I don't think so. I'm not fluent with mc. How can I reproduce
the issue?
Corinna

$ mc -U (to run mc with subshell)
pres CTRL-O (to swith on subshell)
$ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
1112 1 1112 1112 ? 1006 13:42:30 /usr/bin/mintty
556 1112 556 5860 3 1006 13:42:30 /usr/bin/bash
5048 556 5048 2720 3 1006 13:43:00 /usr/bin/mc
2820 5048 2820 2064 0 1006 13:43:00 /usr/bin/bash
460 2820 460 5980 0 1006 13:43:04 /usr/bin/ps
press CTRL-O (to return on mc)
F10 (to exit from mc)
the subshell remains open
$ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
1112 1 1112 1112 ? 1006 13:42:30 /usr/bin/mintty
556 1112 556 5860 3 1006 13:42:30 /usr/bin/bash
I 2820 1 2820 2064 0 1006 13:43:00 /usr/bin/bash
2968 556 2968 5096 3 1006 13:43:42 /usr/bin/ps
sending the SIGHUP
$ kill -SIGHUP 2820
$ ps ax
PID PPID PGID WINPID TTY UID STIME COMMAND
1112 1 1112 1112 ? 1006 13:42:30 /usr/bin/mintty
556 1112 556 5860 3 1006 13:42:30 /usr/bin/bash
5344 556 5344 4804 3 1006 13:44:06 /usr/bin/ps
the subshell closes.

Since I was the person who insisted that this "mc bug" be fixed, I'll
take a look at fixing this unless Corinna has already beaten me to it.

cgf

[Christopher Faylor]

Post by Marco atzeri

Post by Marco atzeri
looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.
Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?
------------- extract from subshell.c --------------
/* Attach all our standard file descriptors to the pty */
/* This is done just before the fork, because stderr must still */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them. */
dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);
close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
case... */
/* Close master side of pty. This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear. */
close (subshell_pty);
/* Execute the subshell at last */
switch (subshell_type)
{
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
----------------------------------------------------------

It seems that mc is correct in the expectation.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
"If fildes refers to the master side of a pseudo-terminal, and this is
the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is the
controlling terminal. It is unspecified whether closing the master side
of the pseudo-terminal flushes all queued input and output."
I don't find such implementation on cygwin
fhandler_pty_master::close ()
Am I looking in the wrong place ?

(checked into this a little more)

Sort of. If the process is doing a read, it is supposed to detect that
the tty has been closed and a SIGHUP is supposed to be sent. It is not
precisely the same thing as sending a SIGHUP when the master closes but
I'm surprised that, in principle, it doesn't amount to the same thing.

Just see any of the SIGHUPs in fhandler_tty.cc. They are all supposed
to be dealing with this scenario.

So, unless bash is not waiting for input (which is unlikely) this should
work.

cgf

[Marco Atzeri]

Post by Christopher Faylor

Post by Marco atzeri

Post by Marco atzeri
looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.
Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?
------------- extract from subshell.c --------------
/* Attach all our standard file descriptors to the pty */
/* This is done just before the fork, because stderr must still */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them. */
dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);
close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
case... */
/* Close master side of pty. This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear. */
close (subshell_pty);
/* Execute the subshell at last */
switch (subshell_type)
{
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
----------------------------------------------------------

It seems that mc is correct in the expectation.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
"If fildes refers to the master side of a pseudo-terminal, and this is
the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is the
controlling terminal. It is unspecified whether closing the master side
of the pseudo-terminal flushes all queued input and output."
I don't find such implementation on cygwin
fhandler_pty_master::close ()
Am I looking in the wrong place ?

(checked into this a little more)
Sort of. If the process is doing a read, it is supposed to detect that
the tty has been closed and a SIGHUP is supposed to be sent. It is not
precisely the same thing as sending a SIGHUP when the master closes but
I'm surprised that, in principle, it doesn't amount to the same thing.
Just see any of the SIGHUPs in fhandler_tty.cc. They are all supposed
to be dealing with this scenario.
So, unless bash is not waiting for input (which is unlikely) this should
work.
cgf

except if bash is sleeping and waiting for signal (or sort of)

http://www.gnu.org/software/bash/manual/bashref.html#Signals

The fact that sending SIGHUP (with $kill -SIGHUP bashpid)
triggers the bash exit, it seems an indication that cygwin is not
correctly handling the situation.

Otherwise there is a bug in bash, and not in mc ;-)

Marco

[Christopher Faylor]

Post by Marco Atzeri

Post by Christopher Faylor

Post by Marco atzeri

Post by Marco atzeri
looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.
Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?
------------- extract from subshell.c --------------
/* Attach all our standard file descriptors to the pty */
/* This is done just before the fork, because stderr must still */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them. */
dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);
close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in
case... */
/* Close master side of pty. This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear. */
close (subshell_pty);
/* Execute the subshell at last */
switch (subshell_type)
{
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
----------------------------------------------------------

It seems that mc is correct in the expectation.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html
"If fildes refers to the master side of a pseudo-terminal, and this is
the last close, a SIGHUP signal shall be sent to the controlling
process, if any, for which the slave side of the pseudo-terminal is the
controlling terminal. It is unspecified whether closing the master side
of the pseudo-terminal flushes all queued input and output."
I don't find such implementation on cygwin
fhandler_pty_master::close ()
Am I looking in the wrong place ?

(checked into this a little more)
Sort of. If the process is doing a read, it is supposed to detect that
the tty has been closed and a SIGHUP is supposed to be sent. It is not
precisely the same thing as sending a SIGHUP when the master closes but
I'm surprised that, in principle, it doesn't amount to the same thing.
Just see any of the SIGHUPs in fhandler_tty.cc. They are all supposed
to be dealing with this scenario.
So, unless bash is not waiting for input (which is unlikely) this should
work.

except if bash is sleeping and waiting for signal (or sort of)
http://www.gnu.org/software/bash/manual/bashref.html#Signals

"sleeping and waiting for signal" would mean that "bash is not waiting
for input". If bash isn't waiting for input that would explain the
problem. However, I would expect that bash, in this scenario, to be
waiting for input. I was hoping you'd provide insight into whether that
was the case or not.

cgf

[Marco Atzeri]

Post by Christopher Faylor
"sleeping and waiting for signal" would mean that "bash is not waiting
for input". If bash isn't waiting for input that would explain the
problem. However, I would expect that bash, in this scenario, to be
waiting for input. I was hoping you'd provide insight into whether that
was the case or not.
cgf

Sorry, I will try to be more clear, for what I understood of mc.

With CTRL-O the foreground is switched between mc and bash
(or viceversa) , so when mc is on foreground bash is not
waiting for input, but for a signal to wake up again.

Mc exits following F10 key press and bash should follow
when it receives SIGHUP.

Marco

[Christopher Faylor]

Post by Marco Atzeri

Post by Christopher Faylor
"sleeping and waiting for signal" would mean that "bash is not waiting
for input". If bash isn't waiting for input that would explain the
problem. However, I would expect that bash, in this scenario, to be
waiting for input. I was hoping you'd provide insight into whether that
was the case or not.
cgf

Sorry, I will try to be more clear, for what I understood of mc.
With CTRL-O the foreground is switched between mc and bash
(or viceversa) , so when mc is on foreground bash is not
waiting for input, but for a signal to wake up again.
Mc exits following F10 key press and bash should follow
when it receives SIGHUP.

I tracked down a place where SIGHUP was not getting sent correctly
so I may have fixed this in recent snapshots. No guarantees though.

cgf

[marco atzeri]

Post by Christopher Faylor

Post by Marco Atzeri

Post by Christopher Faylor
"sleeping and waiting for signal" would mean that "bash is not waiting
for input". If bash isn't waiting for input that would explain the
problem. However, I would expect that bash, in this scenario, to be
waiting for input. I was hoping you'd provide insight into whether that
was the case or not.
cgf

Sorry, I will try to be more clear, for what I understood of mc.
With CTRL-O the foreground is switched between mc and bash
(or viceversa) , so when mc is on foreground bash is not
waiting for input, but for a signal to wake up again.
Mc exits following F10 key press and bash should follow
when it receives SIGHUP.

I tracked down a place where SIGHUP was not getting sent correctly
so I may have fixed this in recent snapshots. No guarantees though.
cgf

Hi cgf,
latest CVS seems to work, I will test more in the coming days.
Thanks.

Not related, but building the test case (on latest CVS)
I noticed a pipe fault.
---------------------------------------------------------
make[3]: Entering directory
`/pub/devel/mc/prova/mc-4.7.5.4-1/build/lib/search'
CC libsearch_la-search.lo
CC libsearch_la-lib.lo
CC libsearch_la-normal.lo
CC libsearch_la-regex.lo
CC libsearch_la-glob.lo
make[3]: *** read jobs pipe: Bad address. Stop.
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory
`/pub/devel/mc/prova/mc-4.7.5.4-1/build/lib/search'
----------------------------------------------------------
the machine was building two programs at the same time with
additional tasks running so a bit loaded.

Regards
Marco

[Christopher Faylor]

Post by marco atzeri

Post by Christopher Faylor

Post by Marco Atzeri

Post by Christopher Faylor
"sleeping and waiting for signal" would mean that "bash is not waiting
for input". If bash isn't waiting for input that would explain the
problem. However, I would expect that bash, in this scenario, to be
waiting for input. I was hoping you'd provide insight into whether that
was the case or not.
cgf

Sorry, I will try to be more clear, for what I understood of mc.
With CTRL-O the foreground is switched between mc and bash
(or viceversa) , so when mc is on foreground bash is not
waiting for input, but for a signal to wake up again.
Mc exits following F10 key press and bash should follow
when it receives SIGHUP.

I tracked down a place where SIGHUP was not getting sent correctly
so I may have fixed this in recent snapshots. No guarantees though.
cgf

Hi cgf,
latest CVS seems to work, I will test more in the coming days.
Thanks.
Not related, but building the test case (on latest CVS)
I noticed a pipe fault.
---------------------------------------------------------
make[3]: Entering directory
`/pub/devel/mc/prova/mc-4.7.5.4-1/build/lib/search'
CC libsearch_la-search.lo
CC libsearch_la-lib.lo
CC libsearch_la-normal.lo
CC libsearch_la-regex.lo
CC libsearch_la-glob.lo
make[3]: *** read jobs pipe: Bad address. Stop.
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory
`/pub/devel/mc/prova/mc-4.7.5.4-1/build/lib/search'
----------------------------------------------------------
the machine was building two programs at the same time with
additional tasks running so a bit loaded.

This problem (and the other fork problem) should be fixed in the
latest snapshot.

cgf