-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Child processes that expect stdin will lock up the process #191
Comments
@PMunch we were discussing this a while ago - have you found any way to replicate the issue? I'm trying to recreate it, but have been unsuccessful. I'm starting to wonder if this is actually a stdin issue, or if it's already been fixed (as of the latest commit to master) |
Haven't noticed it recently after I upgraded to the latest version. But I have modified my configuration to just start one script with nohup and that script then runs all my startup tasks.. |
You could try to write a small Nim program which just writes out a whole bunch to the terminal, and then set that as a startup program. It should fill up the buffer and lock up. And I don't think it was Nimdow itself locking up was it? I think it was only that process locking up (which in my case meant that my statusbar stopped working). |
Aha, thanks for the reminder. I'll try this out. |
Through some testing, I've also found that processes spawned when Nimdow starts do not close when Nimdow exits. This can lead to some undesirable behavior, since multiple instances of the same process will be running if Nimdow is "restarted". |
Describe the bug
Have one of the autostart programs wait for stdin.
It will block and the process will lock up.
Additional context
Probably can just use nohup to get around this, e.g.
nohup "$@" &>/dev/null &
Need to ensure redirection from within the user command still works as intended.
The text was updated successfully, but these errors were encountered: