3

So I have a bash script which will notify me, if the battery is low.

The script is here

#!/bin/bash

BATTERY=$(upower -e | grep 'BAT')

while :
do
    BATTERY_PERCENTAGE=$(upower -i $BATTERY | grep percentage | awk '{ print $2 }' | sed s/'%'/''/g)
    CABLE=$(upower -d | grep -n2 line-power | grep online | awk '{ print $3 }')

    if [[ "$BATTERY_PERCENTAGE" -lt "10" && $CABLE = "no" ]]; then
        notify-send --urgency=critical "WARNING: Battery is about to die"  "Plug in the power cable"
    fi

sleep 60

done

So I am currently using the dwm window manager with Arch Linux. The issue is that if I just close the window manager, & again launch it, it actually shut down all the programs I was using (for instance flameshot & dunst), but it fails to kill my battery script. Here is my autostart script which I am running in .xinitrc file.

# My .xinitrc file
# This file will run as autostart

dunst &
flameshot &
setxkbmap -option caps:escape &
sxhkd -c ~/suckless/dwm/sxhkdrc &
~/.fehbg &
~/scripts/battery-notification & 
xrdb ~/.Xresources &
exec dwm

And I run this file through xorg's startx. If I do a ps -ef | grep battery-notification, it shows more than 2 instances (which include battery script & grep).

Answers are appreciated :)

Improve this question
4
  • Please check what you're writing. In the question you say, "it fails to kill my battery script", but in a comment you say, "it actually kills all the instances of the battery script". Which is it? Commented Sep 23, 2021 at 8:41
  • @roaima I thought that the "it actually kills all the instances" only applies to Praveen Kumars solution, and that OP therefore considers that solution unsuitable (because one instance should be kept running). Commented Sep 23, 2021 at 8:55
  • OP then continues "I actually need 1 running in the background" which is still at odds with the question Commented Sep 23, 2021 at 9:07
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. Commented Sep 25, 2021 at 0:01

3 Answers 3

Reset to default
3

You could add a lockfile mechanism to your script. Just make sure that the lockfile is reliably deleted when the script exits, e.g. by setting a trap:

#!/bin/bash

lockfile="/var/run/lock/batterystatus.lock"

if [[ -e "$lockfile" ]]; then exit 0; fi

trap 'rm -f "$lockfile"' EXIT
touch "$lockfile"

# ... your actual script code here

Please note that in case the script is terminated with SIGKILL, the trap will not be sufficient to reliably remove the lockfile.

After a helpful clarification by Kamil Maciorowski, here is an improved version using flock.

#!/bin/bash

lockfile="/var/run/lock/batterystatus.lock"
exec 100>"$lockfile"
if ! flock -n 100; then exit 0; fi

# ... your actual script here

This will create the lockfile if necessary, and redirects the file descriptor 100 (chosen almost arbitrarily)(1) to the lockfile. It then tries to get a lock on that file descriptor via flock. If that succeeds, the lock will be held until the script exits. If, on the other hand, another script instance already has a lock on that file descriptor, the script will exit immediately.

Note that there is no need to clean up the lockfile - the lock performed by flock is what's relevant here. This also means that the existence of the lockfile doesn't mean the script shouldn't be started - only the presence of a lock on that file does.

The idea is taken from here. For further reading, have a look at

  • bash flock: exit if can't acquire lock (here you see that you can even use the script file itself as the lockfile - as already stated, it is only the lock that counts, not the presence/absence of the file).

(1) If you have Bash > 4.1, you can have the shell auto-allocate a free file descriptor via the {variable-name}>redirection-target-Syntax, as in:

exec {lockfd}>"$lockfile"
if ! flock -n "$lockfd"; then exit 0; fi

The shell will find the next free file descriptor (with the limitation that only descriptor numbers > 9 are used), and store the actually used descriptor in the variable $lockfd for further use.

Improve this answer
2
  • @KamilMaciorowski I see, then you have clarified a (huge) misunderstanding on my part here, thank you :) ! Commented Sep 23, 2021 at 9:37
  • 1
    @AnantGupta You're welcome! If you found the answer useful, please consider accepting it so that others facing a similar issue may find it more easily. Commented Sep 24, 2021 at 10:31
0

I haven't tried it, but this may work:

At the top of your .xinitrc script:

trap 'kill 0' EXIT

This will kill all processes in your process group. You may not want to exec the dwm at the end. Just give it dwm without the exec; that will keep the parent bash shell open until the dwm dies.

Improve this answer
2
  • It doesn't work for me, I added this in my xinitrc file. This won't kill the extra process ${trap 'kill 0' EXIT} & I tried to add the original one that you sent, but it threw some error. Using $( trap 'kill 0' EXIT) also made an error. Also, simply using the command won't kill the extra process running Commented Sep 23, 2021 at 4:01
  • @AnantGupta Don't put the ${ or $( in there. The trap command is written in your script exactly as posted. But you said it didn't work? What was the error? Commented Sep 24, 2021 at 13:42
-2 
You can add below commands to kill the battery script while logging in

ps -eaf | awk 'BEGIN{IGNORECASE=1}/battery/ && !/awk/{print "kill -9 "$2}'| sh
Improve this answer
1
  • 2
    The problem with it is that it actually kills all the instances of the battery script. I actually need 1 running in the background Commented Sep 23, 2021 at 2:57

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.