[Solved] How do I isolate an app instance for bash script

sleekmason · 2020-12-03 18:21:44

Horrible title, probably a simple solution. pffft:)

Okay here's the whole scenario. currently using a simple toggle for wbar, with its config in ~/.wbar (app default).

I want to leave this as is (and may not matter to this equation), for autostart purposes, etc..

I want a separate wbar panel only for a set of toggles. Hit a button and the whole set pops up, ready for punching.

I can create another config in ~/.config/wbar/wbar-toggles, and call it with:

wbar --config ~/.config/wbar/wbar-toggles

, and everything is groovy.

The problem of course is the exiting of only this configuration (wbar-toggles) when using a toggle, and not the other(wbar), should both be activated.

The current simple toggle of:

bash -c 'if ! pkill -x wbar; then exec wbar; fi'

I would prefer to keep in place as is.

So, The question is: How to grab only wbar-toggle to be killed?

pkill -x wbar-toggles and variations thereof isn't cutting it - (progress! - this time I knew it wouldn't and tried it anyway:) lol.

Guessing the below will be closer to the format required?.

#!/bin/bash
if pgrep -f wbar-toggles > /dev/null; then
    pkill -f wbar-toggles
else
    wbar --config ~/.config/wbar/wbar-toggles &
fi

Anyhow, Help Please! big_smile

Last edited by sleekmason (2020-12-03 21:09:31)

twoion · 2020-12-03 19:21:54

With systemd, there is a very simple solution:

systemd-run --user --collect --unit wbartoggles --wait wbar --config ~/.config/wbar/wbar-toggles || true

You might have to add --setenv=DISPLAY=$DISPLAY to the options when launching this from a script.

The command will run the wbar command as the unit wbartoggles when runs, and the command will fail to run the unit wbartoggles if the unit already exists -- that means, as long as another wbartoggles is running, it'll remain the only one that can run. If you need more logic, you can replace the wbar command in the systemd-run invocation with a call to a Bash script that implements the logic.

systemd-run does not seem to work in a BL live CD session, but in a any properly installed system this should work.

Without systemd, how about this, if I understand you post correctly:

LOCKFILE="/run/user/$UID/wbar-toggles.pid"
TERMINATION_LOCK="$LOCKFILE.lock"
if [[ -e $LOCKFILE && ! -e $TERMINATION_LOCK ]]; then
  {
    touch "$TERMINATION_LOCK"
    PID=$(<$LOCKFILE)
    kill -SIGTERM $PID
    if tail --pid=$PID </dev/null; then
       rm -- "$LOCKFILE"
       rm -- "$TERMINATION_LOCK"
    fi
  }&
else
  wbar --config ~/.config/wbar/wbar-toggles &
  echo $! >"$LOCKFILE"
fi

ohnonot · 2020-12-03 19:55:08

Good to know about the systemd solution.

Lacking that knowledge (or systemd) I'd have said you'll need a lockfile - as twoion pointed out.

edit:
I used to use this function in some scripts:

function only_me_or_exit {
# argument: pidfile
# make sure only 1 instance is running
touch "$1"
read lastPID < "$1"
# if lastPID is not null and a process with that pid exists , exit
[ ! -z "$lastPID" -a -d /proc/$lastPID ] && { echo "An instance of $me is already running with pid $lastPID." ; exit 1 ; }
# else - save my pid in the lock file, and continue
echo $$ > "$1"
}

Last edited by ohnonot (2020-12-03 19:57:28)

sleekmason · 2020-12-03 21:08:48

twoion wrote:

With systemd, there is a very simple solution:
systemd-run --user --collect --unit wbartoggles --wait wbar --config ~/.config/wbar/wbar-toggles || true
You might have to add --setenv=DISPLAY=$DISPLAY to the options when launching this from a script.
The command will run the wbar command as the unit wbartoggles when runs, and the command will fail to run the unit wbartoggles if the unit already exists -- that means, as long as another wbartoggles is running, it'll remain the only one that can run. If you need more logic, you can replace the wbar command in the systemd-run invocation with a call to a Bash script that implements the logic.
systemd-run does not seem to work in a BL live CD session, but in a any properly installed system this should work.
Without systemd, how about this, if I understand you post correctly:
LOCKFILE="/run/user/$UID/wbar-toggles.pid"
TERMINATION_LOCK="$LOCKFILE.lock"
if [[ -e $LOCKFILE && ! -e $TERMINATION_LOCK ]]; then
  {
    touch "$TERMINATION_LOCK"
    PID=$(<$LOCKFILE)
    kill -SIGTERM $PID
    if tail --pid=$PID </dev/null; then
       rm -- "$LOCKFILE"
       rm -- "$TERMINATION_LOCK"
    fi
  }&
else
  wbar --config ~/.config/wbar/wbar-toggles &
  echo $! >"$LOCKFILE"
fi

Yes! This does the trick nicely:)
More than one use for this.
FYI Gave this warning on close in a terminal

tail: warning: PID ignored; --pid=PID is useful only when following

Guessing used for something more in the script? anyway, it works!

@ohnonot

function only_me_or_exit {
# argument: pidfile
# make sure only 1 instance is running
touch "$1"
read lastPID < "$1"
# if lastPID is not null and a process with that pid exists , exit
[ ! -z "$lastPID" -a -d /proc/$lastPID ] && { echo "An instance of $me is already running with pid $lastPID." ; exit 1 ; }
# else - save my pid in the lock file, and continue
echo $$ > "$1"
}

Heh, You have to feed it to me with the item in place or I am lost! big_smile

brontosaurusrex · 2020-12-03 21:43:22

Assuming you had a script called wbar2 and that would include your custom wbar startup and a line like

trap 'kill $(jobs -p) >/dev/null 2>&1' EXIT
# kills its children on exit ^
# your custom wbar start here

then your toggle script might work as expected, something like

#!/bin/bash
if pgrep -f wbar2> /dev/null; then
    pkill -f wbar2
else
    wbar2
fi

Just a thing I used in some of my scripts, but don't remember the exact details. I think it is neat, with no need to do any pid hunting.

Last edited by brontosaurusrex (2020-12-03 22:09:35)

sleekmason · 2020-12-03 22:49:17

brontosaurusrex wrote:

Assuming you had a script called wbar2 and that would include your custom wbar startup and a line like
trap 'kill $(jobs -p) >/dev/null 2>&1' EXIT
# kills its children on exit ^
# your custom wbar start here
then your toggle script might work as expected, something like
#!/bin/bash
if pgrep -f wbar2> /dev/null; then
    pkill -f wbar2
else
    wbar2
fi
Just a thing I used in some of my scripts, but don't remember the exact details. I think it is neat, with no need to do any pid hunting.

Yes! this works flawlessly. Thank you.

johnraff · 2020-12-04 00:45:47

There already seem to be several solutions, but I'm throwing in that with the right regular expression pgrep should be able to pick out the specific wbar launched with a certain config file. Test with:

pgrep -fxa 'wbar --config ~/.config/wbar/wbar-toggles'

If there's a possibility of other options coming in between wbar and --config then tweak the regex a bit, eg simplest version:

'wbar( .+)* --config ~/.config/wbar/wbar-toggles'

But that doesn't look necessary for your case, where the command line is well-defined.

So a toggle command for wbar-toggles substituting pkill for pgrep should also be easy.

#1 2020-12-03 18:21:44

[Solved] How do I isolate an app instance for bash script

#2 2020-12-03 19:21:54

Re: [Solved] How do I isolate an app instance for bash script

#3 2020-12-03 19:55:08

Re: [Solved] How do I isolate an app instance for bash script

#4 2020-12-03 21:08:48

Re: [Solved] How do I isolate an app instance for bash script

#5 2020-12-03 21:43:22

Re: [Solved] How do I isolate an app instance for bash script

#6 2020-12-03 22:49:17

Re: [Solved] How do I isolate an app instance for bash script

#7 2020-12-04 00:45:47

Re: [Solved] How do I isolate an app instance for bash script

Board footer