Polybar kills all children of processes it spawns? #770
Comments
|
I don't exactly know how polybar handles its child processes, but it makes sense that it cleans up after itself, otherwise you end up with a bunch of processes spawned by polybar which run in the background (not necessarily doing anything or outputting text to the bar without the bar listening for it) or you may even get zombie processes, if they're not handled correctly. But what you want to achieve is possible inside the script, with one of the following ways: nohup: nohup mpv http://myserver &>/dev/null &disown: mpv http://myserver &
disownsetsid: setsid mpv http://myserver &>/dev/null < /dev/null &The |
|
Thank you for the super-thorough explanation. The |
Shell commands triggered from action tags used to block polybar until they finished. Since we are not actually interested in the output of the commands, it makes sense to run them completely detached from polybar and have polybar not block when executing these commands. Now the spawned child processes no longer get killed when polybar exits. This is fine because polybar is not responsible for these processes since they were explicitly started by the user through click commands. Ref: polybar#770
|
Just FYI, I have just pushed #2248 which will make polybar no longer kill children spawned through click (and scroll) commands. Programs launched through polybar now act more or less the same as if they were started from some application launcher. EDIT: This should make it into the 3.5.0 release |
Shell commands triggered from action tags used to block polybar until they finished. Since we are not actually interested in the output of the commands, it makes sense to run them completely detached from polybar and have polybar not block when executing these commands. Now the spawned child processes no longer get killed when polybar exits. This is fine because polybar is not responsible for these processes since they were explicitly started by the user through click commands. Ref: polybar#770 Ref: polybar#1680
Shell commands triggered from action tags used to block polybar until they finished. Since we are not actually interested in the output of the commands, it makes sense to run them completely detached from polybar and have polybar not block when executing these commands. Now the spawned child processes no longer get killed when polybar exits. This is fine because polybar is not responsible for these processes since they were explicitly started by the user through click commands. Ref: polybar#770 Ref: polybar#1680
Shell commands triggered from action tags used to block polybar until they finished. Since we are not actually interested in the output of the commands, it makes sense to run them completely detached from polybar and have polybar not block when executing these commands. Now the spawned child processes no longer get killed when polybar exits. This is fine because polybar is not responsible for these processes since they were explicitly started by the user through click commands. Ref: #770 Ref: #1680
|
@patrick96 I am on 3.5.0, and now, even the simplest command executed with mouse click (e.g. notify-send "hello" "world") leaves a zombie process. See the screenshot below. These processes do not seem to disappear after a while. They (obviously) are removed after polybar is restarted. |
Since the forked processes are still our children, we need to wait on them, otherwise they become zombie processes. We now fork twice, let the first fork immediately return and wait on it. This reparents the second fork, which runs the actual code, to the init process which then collects it. Ref polybar#770
Since the forked processes are still our children, we need to wait on them, otherwise they become zombie processes. We now fork twice, let the first fork immediately return and wait on it. This reparents the second fork, which runs the actual code, to the init process which then collects it. Ref polybar#770
Since the forked processes are still our children, we need to wait on them, otherwise they become zombie processes. We now fork twice, let the first fork immediately return and wait on it. This reparents the second fork, which runs the actual code, to the init process which then collects it. Ref #770
|
@pawel-szopinski Hmm, I though I tested this exact thing, but I guess I did not. I fixed this in #2285, this will be in the 3.5.1 release. |
Changelog **Features** * config: Multiple inheritance (#2271), see #2269 **Fixes** * (#2285), see #770, #2289 * Timer module: Polybar crash when interval is set to 0 (#2274), see #2273 * `custom/menu`: Wrong level numbers in error messages (#2264) * `internal/xworkspaces`: Ignored certain workspace updates (#2275), see #2272 * Logger: Undefined behavior (#2284) * build: * Build issues in older clang versions (#2270, #2279, #2280)
|
@patrick96 big thanks for the quick fix! I can confirm it is indeed resolved in 3.5.1. |
|
Thank you! |
So, I have a shell script that launches
mpvin the background to connect to my remote MPD server:If I launch this from the command line, everything works as it should,
mpvruns in the background even if I close the terminal, etc. However, if I try to hook it up to mympdmodule in polybar (so that I can actually listen to the stream that I am remote-controlling with the module) like so:then something strange happens: the
mpvprocess is killed as soon asstream-mpdexits. I can confirm this by adding asleep 10as the last line of my script: polybar will freeze up for 10 seconds since the script is running, but then once the 10 seconds are up,mpvis killed too! I can't explain why that happens - is polybar going out of its way to clean up the children of all the processes it spawns? Is there a way to accomplish what I'm after (which is to start a background task as an input trigger)?The text was updated successfully, but these errors were encountered: