Help troubleshooting a bash script on gnome

I think this is the most relevant category vs programming since this bit of scripting worked prior to the last update (if the mods think gnome has no relevance here then feel free to move it to programming? I guess). I’m not sure if it is a problem with sudo or if it is a problem with changes in x11/wayland. I just know this script worked fine for over a year now and stopped functioning with the last Stable update on 5-6-2021.

Basically I use this as a function in several scripts that perform various tasks from backups to btrfs maintenance, etc… Anyway I didn’t write the original script I found it online but as I said it has functioned perfectly until the last update. The purpose is to essentially send notifications to my users notification bar upon successful completion. It was necessary since most of these jobs run under the root cron job scheduler.

Below is a the very bare bones script that included and then used the function to print a test message. This used to work if run as a user or with sudo and still showed the notifications on my users notification desktop. (versus if I just execute a notify-send command as myself I get the message but if I do so as sudo my notification bar never gets the message which is why I found this tidbit of code in the first place).

I’m now getting sudo errors so I’m not sure what changed in the last update.

Here is the script:

function notifysend()
    #Detect the name of the display in use
    local display=":$(ls /tmp/.X11-unix/* | sed 's#/tmp/.X11-unix/X##' | head -n 1)"

    #Detect the user using such display
    local user=$(who | grep '('$display')' | awk '{print $1}' | head -n 1)

    #Detect the id of the user
    local uid=$(id -u $user)

    sudo -u $user DISPLAY=$display DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus notify-send "$@"
    echo $user $display $uid

notifysend "Test message" "Details2" --icon=emblem-default

not sure i understand, you should not be running the notification as sudo.
you can:
sudo my_script; zenity --notification --text=“your script finished”

(zenity is gnome standard, man zenity or zenity --help)

zenity does much more, for example if you want a popup, zenity --info

forgot to mention can do the zenity command in a script & call that to save typing.

Maybe if you give the errors you get it could help?

Also do individual lines work as intended?

1 Like

That script works for me on kde.
It depends on the user using X11. Are you sure you’re not using wayland?


Thank you for the replies:

The errors I get when I run the script as myself are:

sudo: unknown user: DISPLAY=:0
sudo: error initializing audit plugin sudoers_audit
:0 1000

The errors if I run as sudo are:

sudo: unknown user: DISPLAY=:0
sudo: error initializing audit plugin sudoers_audit
:0 0

@kerry_s I’ll look into zenity however, the reason I pointed out running it as sudo was for TESTING purposes. This bit of code runs as root (It is the reporting piece of my backup and various btrfs maintenance jobs that require root to run so they are run under the root’s crontab). The entire point is I leave my computer logged on as me 24/7 and I want when I log into my computer to have a quick little message that says the jobs executed ok or not. If they didn’t then I can go into the logs and see why a particular job failed.

I’m thinking it has to do with sudo based on the errors but the last update didn’t generate any .pacnew files so I’m not sure what changed in the configuration that allowed this to run for over a year flawlessly (the script I posted above is what I used originally to test, when it originally was tested it would create the test message in my notifications and if I ran the script under sudo it would also create the notification on my desktop.

As far as X11 vs. Wayland as far as I know I’m still using X11. The output of loginctl:

3 1000 craig seat0 tty2

1 sessions listed.

loginctl show-session 3 -p Type

It’s my understanding that means I’m running X11 but I honestly am not sure. The scripts I have running using this run every single day for over a year now and after this last update I noticed I wasn’t getting notifications however the jobs where running that is when I started looking into what was up and found that the “function” was using my bash script no longer was working.

While I understand the basics of what the script is doing I just don’t know enough to know why it is failing. I’m guessing maybe something changed with sudo that is now causing this behavior for some reason.

like i said run a bash script that does your sudo, then normal notifications.
have your cron job run:
execute my sudo script; my notification not running as sudo with normal access to display.

gnome has made great strides in security, i know as a user we like to bypass these things, but etc…

I need the the exit codes from the backup program to determine if the job was successful or not. So it needs to be determined at the time the backup script is running when the backup program finishes up. That is why the message needs to be sent from within that script and that script is running with elevated privileges in order to backup all files. Based on that exit code INSIDE the original script is what determines whether it sends me a message saying the backup was a success/failure/or ended with errors. The point is this has worked for over a year and something just changed in the last update that broke this. I’m trying to figure out what was changed in the environment with sudo that this no longer works anymore. Gnome is just a desktop environment this is run entirely from bash so having root send a message to a users Gnome desktop isn’t any kind of security issue. It’s root it should have permission to send a message to a users notification.

The first part of the script determines which desktop you are running on, then it determines your userid then it basically sends the message as you. All things that root should be able to do.

The example you are giving me just would let me know that the script ran. The script is running daily without an issue. I just want a quick notice on whether it was successful without looking into the logs.

okay, i understand

sudo is receiving DISPLAY=:0 as the username, ie $user is empty, which you can also see from your output at the end lacking the username (and the fact the uid changes when run with sudo). It depends on the success of the line above, but that seems to work since we get :0

What’s the output of who?

# Generally IMO using "" is nicer and less error prone
# Also works without the () around $display, on my system at least
user=$(who | grep "($display)" | awk '{print $1}' | head -n 1) 

However both that and your version work as expected for me, as my user, using sudo and from root. (in both bash and zsh)


Oops, missed a line in root. :man_facepalming:
Removed mis-information.