sumeet/golden

run.sh should kill any previously existing golden processes

Opened this issue · 5 comments

If you have run.sh in your bspwmrc and you reload bspwm a new run.sh and run.py processes will start. I found myself yesterday inadvertedly with around 25 run.sh and run.py processes in the background, which I had to kill one by one because I didn't know how to perform a killall on them.

So run.sh should have a way to kill any previous process before it starts, much like you have for sxhkd in your example.

Hey cool, I didn't know anyone was using this 🙂

Can you give the latest version a try? This should take care of killing off the child processes.

I found this script on the bspwm subreddit and been using it since.

Reading the stackoverflow thread it seems the trap part is to kill processes once the script is exited, but there's a problem:

If you execute run.sh in bspwmrc, when you restart bspwm the process is simply spawned again. So any child processes from the first script don't get killed because the first script itself just keeps running.

You can easily try it yourself, just do bspc wm -r (mod + alt + r in my case) and then search htop for golden. You should see two run.sh and two golden.py. Restart bspwm again and you will see three, etc.

I submitted a PR with my own implementation, I don't know if it's totally correct but so far it seems to work fine. Please read the commit message and see how you feel about it.

What’s the best way to repro through normal usage? Are you killing and
relaunching bspwm manually, or using a bspc command to do it?

You were quick to reply. See the edit I made:

You can easily try it yourself, just do bspc wm -r (mod + alt + r in my case) and then search htop for golden. You should see two run.sh and two golden.py. Restart bspwm again and you will see three, etc.

Couple initial impressions:

  1. Can you eliminate the while-true loop in run.sh? Is it just for resilience to crashes?
  2. golden.py should ideally exit when bspwm exits --- I think preferably it would detect that its stdin is closed. Is this already happening and being covered up by the while-true loop? Or is there some issue in the Python code where it doesn't detect this as expected? Or am I just misunderstanding the relationship between bspc subscribe and golden.py?