Why do we close stdin in (some) spawned processes?

Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Why do we close stdin in (some) spawned processes?

ivan
In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' from xmonad-contrib we do not. I'm curious why that's the case?

This commit introduced the code that closes stdin, but doesn't describe the motivation for doing so:

I suspect we close stdin in 'spawn' because we know it won't be needed, but I'm still not sure what we gain by closing it (does it improve efficiency?). And should we be closing it in 'safeSpawn' as well, or does 'safeSpawn' have a use-case that requires reading from stdin?

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Why do we close stdin in (some) spawned processes?

Brandon Allbery
Probably we should not be closing it; or at least should have it open on /dev/null. There is a general expectation in the POSIX model that fds 0, 1, 2 are open.

On Tue, Jan 12, 2021, 10:06 ivan <[hidden email]> wrote:
In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' from xmonad-contrib we do not. I'm curious why that's the case?

This commit introduced the code that closes stdin, but doesn't describe the motivation for doing so:

I suspect we close stdin in 'spawn' because we know it won't be needed, but I'm still not sure what we gain by closing it (does it improve efficiency?). And should we be closing it in 'safeSpawn' as well, or does 'safeSpawn' have a use-case that requires reading from stdin?
_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Why do we close stdin in (some) spawned processes?

Tomáš Janoušek
In reply to this post by ivan
HTML E-Mail

Hi Ivan,

On Tue, Jan 12, 2021 at 10:06:06AM -0500, ivan wrote:

In 'spawn', we close stdin in the child process, whereas in 'safeSpawn'
from xmonad-contrib we do not. I'm curious why that's the case?

This commit introduced the code that closes stdin, but doesn't describe the
{.quotelead}>motivation for doing so:

https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3

When you log in on a vt and do "startx $(which xmonad)", xmonad runs with fds 0, 1 and 2 connected to /dev/ttyN. If it didn't close (actually redirect from /dev/null) stdin, some programs might think they're being run from the terminal, I guess, and/or perhaps get stuck reading from it.

This is obviously a rather non-standard way of launching xmonad, so probably irrelevant, but:

The less unusual "startx" without arguments (having xmonad in .xinitrc or .xsession), /etc/X11/xinit/xinitrc invokes /etc/X11/Xsession which redirects stdout and stderr to .xsession-errors (this may be distro-specific, I'm on Debian), but it does not touch stdin, so that issue probably remains. I can't think of a specific app that breaks, off the top of my mind, but I'd be surprised if there weren't any.

And should we be closing it in 'safeSpawn' as well, or does
'safeSpawn' have a use-case that requires reading from stdin?

I can't think of any such use-case. Using 'xfork' in 'safeSpawn' should be just fine.

--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Why do we close stdin in (some) spawned processes?

ivan
In reply to this post by Brandon Allbery
Actually, I misspoke (and so did the commit message) -- we aren't closing stdin, but rather redirecting it to /dev/null.

On Tue, Jan 12, 2021 at 10:13 AM Brandon Allbery <[hidden email]> wrote:
Probably we should not be closing it; or at least should have it open on /dev/null. There is a general expectation in the POSIX model that fds 0, 1, 2 are open.

On Tue, Jan 12, 2021, 10:06 ivan <[hidden email]> wrote:
In 'spawn', we close stdin in the child process, whereas in 'safeSpawn' from xmonad-contrib we do not. I'm curious why that's the case?

This commit introduced the code that closes stdin, but doesn't describe the motivation for doing so:

I suspect we close stdin in 'spawn' because we know it won't be needed, but I'm still not sure what we gain by closing it (does it improve efficiency?). And should we be closing it in 'safeSpawn' as well, or does 'safeSpawn' have a use-case that requires reading from stdin?
_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Why do we close stdin in (some) spawned processes?

ivan
In reply to this post by Tomáš Janoušek
Thanks for the explanation, that makes sense. I looked at the history of 'safeSpawn' and interestingly, it used to call xfork, but that was changed in this commit:

The issue described in that commit, though, seems to be related to signal handlers rather than stdin (though it also sounds like the exact issue may not have been identified).

On Tue, Jan 12, 2021 at 3:46 PM Tomas Janousek <[hidden email]> wrote:

Hi Ivan,

On Tue, Jan 12, 2021 at 10:06:06AM -0500, ivan wrote:

In 'spawn', we close stdin in the child process, whereas in 'safeSpawn'
from xmonad-contrib we do not. I'm curious why that's the case?

This commit introduced the code that closes stdin, but doesn't describe the
{.quotelead}>motivation for doing so:

https://github.com/xmonad/xmonad/commit/353e7cd6811245fbee7c8c6cf821041c924523b3

When you log in on a vt and do "startx $(which xmonad)", xmonad runs with fds 0, 1 and 2 connected to /dev/ttyN. If it didn't close (actually redirect from /dev/null) stdin, some programs might think they're being run from the terminal, I guess, and/or perhaps get stuck reading from it.

This is obviously a rather non-standard way of launching xmonad, so probably irrelevant, but:

The less unusual "startx" without arguments (having xmonad in .xinitrc or .xsession), /etc/X11/xinit/xinitrc invokes /etc/X11/Xsession which redirects stdout and stderr to .xsession-errors (this may be distro-specific, I'm on Debian), but it does not touch stdin, so that issue probably remains. I can't think of a specific app that breaks, off the top of my mind, but I'd be surprised if there weren't any.

And should we be closing it in 'safeSpawn' as well, or does
'safeSpawn' have a use-case that requires reading from stdin?

I can't think of any such use-case. Using 'xfork' in 'safeSpawn' should be just fine.

--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad
Reply | Threaded
Open this post in threaded view
|

Re: Why do we close stdin in (some) spawned processes?

Tomáš Janoušek
HTML E-Mail

On Tue, Jan 12, 2021 at 05:29:15PM -0500, ivan wrote:

Thanks for the explanation, that makes sense. I looked at the history of
'safeSpawn' and interestingly, it used to call xfork, but that was changed
{.quotelead}>in this commit:

https://github.com/xmonad/xmonad-contrib/commit/1844c80978844611f7d409cab7c313bb0c0649bf

That commit makes no sense. xfork always did uninstallSignalHandlers. Actually, xfork is still exactly the same function it was in 2009 when it appeared for the first time.

The only exaplanation I have is that the reporter of https://code.google.com/archive/p/xmonad/issues/441 used xmonad-contrib that didn't use xfork yet (that is, before https://github.com/xmonad/xmonad-contrib/commit/e8c0f39fd5238771d14b920b8b87f89e7b56c30f), and reported an issue which gwern tried to fix without knowing it'd already been fixed but the reporter isn't running the fix yet, and pushed yet another fix (1844c8097 that you mentioned) but forgot about stdin. This explanation assumes the problem was in signal handling, but the discussion in https://code.google.com/archive/p/xmonad/issues/441 looks like it was, indeed.

So I think 1844c8097 can just be reverted, the issue was most probably already fixed by e8c0f39fd5.

The issue described in that commit, though, seems to be related to signal
handlers rather than stdin (though it also sounds like the exact issue may
not have been identified).

--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/

_______________________________________________
xmonad mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad