BunsenLabs / bunsen-utilities

https://pkg.bunsenlabs.org/debian/pool/main/b/bunsen-utilities/
GNU General Public License v3.0
31 stars 21 forks source link

bl-tint2-zen/bl-tint2-session "orphan" processes? #12

Closed capn-damo closed 9 years ago

capn-damo commented 9 years ago

tint2's are started from commands kept in the sessionfile, with source "$SESSIONFILE" This creates another process for each tint2 which was started, called /bin/bash /home/damo/bin/bl-tint2-session or /bin/bash /home/damo/bin/bl-tint2zen

They can be killed manually later without killing the tint2's, but killing the PIDs within the scripts kills the tint2's as well. My bash skills aren't good enough to have found a solution :(

johnraff commented 9 years ago

Do these extra processes show up with this autostart line: (sleep 2s && bl-tint2-session --autostart) & or this one: (sleep 2; tint2) & ?

capn-damo commented 9 years ago

Do these extra processes show up with this autostart line: (sleep 2s && bl-tint2-session --autostart) & ? Yes. The extra processes finish when killall tint2 is then used. I can also kill the individual extra processes without stopping the tint2's.

(sleep 2; tint2) & No. The only PID is for tint2

johnraff commented 9 years ago

It might be the way tint2 is launched. I had a look in ~/.config/tint2/tint2-sessionfile and found: tint2 -c /home/john/.config/tint2/tint2rc && sleep 1s & I don't see any purpose in the sleep tbh, but more important, the final & forks off tint2 and leaves the script waiting for it to exit. When that tint2 process is killed the parent script process will die too. OTOH the reason killing the script pid doesn't kill tint2 is, I guess, because tint2 is forking itself again.

If you don't need the script to do anything after launching tint2 then you could use exec: the script process will be taken over by tint2. Like: exec tint2 -c /home/john/.config/tint2/tint2rc

OTOH if the script has to go on and do other stuff after that tint2 launch then it will need some more thought...

capn-damo commented 9 years ago

I've tried it with and without the final &, and with an exit command immediately after forking it. Without & the first tint2 runs, but a second doesn't start until the first is stopped. I was wondering if it is to do with sourcing the commands?

I'll try with exec

capn-damo commented 9 years ago

OK, this works: The sessionfile just has the path/to/tint2rc, with no tint2 command The script reads the file ("$1")instead of sourcing it... while read line;do tint2 -c "$line" & sleep 1s done < "$1"

Looks like it was the && sleep which was the issue

johnraff commented 9 years ago

That looks good.

Come to think of it, exec would only work if you were only launching a single tint2. If you wanted to fire off multiple completely forked off processes you might try setsid like this: (setsid tint2 -c "$line" & ) in case the parent-child relationship was still causing problems.

Try in a terminal the difference between leafpad & and (setsid leafpad &). In the second case you can kill the terminal and leafpad remains.