[DONE] RFT: notify-broadcast

johnraff · 2016-09-02 07:49:51

WHY: I've been searching for a way for root processes to send messages to logged-in users.
The specific case in mind was a systemd timer, calling a systemd service. I wanted some notification if the service failed. (brief details below, for those interested)
It's relatively easy to send an email, or possibly a "wall" message, but I wanted to use "notify-send", for something a bit more stylish.

Googling shows that if run by root, notify-send needs to know the DISPLAY to send to (fair enough) and the XAUTHORITY cookie location (usually ~/.Xauthority), or possibly a DBUS address. Alternatively, if run as

sudo -u username DISPLAY=whatever notify-send "title" "message" ...etc

it also uses username's theming configs, so the popup window fits in nicely. In a multi-user multi-screen setup those two values aren't to be taken for granted.

I chose to parse the output of 'w -hs' to pull out the usernames and "remote host" for each login user. If the "remote host" value started with a colon I used it as a display number. This script then runs the above command for each user/display found from 'w', allowing root processes to send a notify-send message to all users logged in with an X session running. That's the intention anyway.

QUESTIONS:
(1 ~ 3 are for techy folks, 4 is for everyone.)

Is there an easier or cleaner way to send notification messages from a failed systemd service?
If notify-send is OK, is there a better way to get the usernames and DISPLAY numbers of currently logged-in users?
If it's basically on the right lines, could anything else in the script be improved?
Does the script here do what it should?

SETUP:
Please copy the code below into a file, and as root, put it in /usr/bin/notify-broadcast, and make it executable. ('sudo chmod +x /usr/bin/notify-broadcast')

TEST:
Try any of the commands below from a terminal, and report if the popup message appeared:

notify-broadcast --help # should output a short message, and exit 0
notify-broadcast # should output an error message and exit 1
sudo notify-broadcast 'Title' 'Any message you like' --icon=dialog-error # or some other icon
sudo notify-broadcast ...any notify-send arguments you like... # all should work

If you have a root password, open a new tty (Ctrl+Alt+2 or 3...), login as root and try some of the same commands. If you switch quickly back to tty7 (Ctrlk+Alt+7) you should see the notification popup.

If you have a second machine handy, and have enabled ssh access, try passing the same commands in by ssh. This will probably be the most likely to fail.

Here's the script:

#!/bin/bash

HELP="Call notify-send for all current X users.
Passed arguments are sent on as-is.
This script must be run as root."

error_exit() {
    echo "$0 error: $1" >&2
    exit 1
}

case $1 in
--help|-h)
    echo "$HELP"
    exit
    ;;
esac

[[ $( id -u ) -eq 0 ]] || error_exit "This script must be run as root."

declare -A DISPLAYS
DISPLAYS=()

while read user tty from other
do
    [[ $from = :?* ]] || continue
    DISPLAYS["$user"]="$from"
done < <( w -hs )

for i in "${!DISPLAYS[@]}"; do
    sudo -u "$i" DISPLAY="${DISPLAYS[$i]}" notify-send "$@"
done

exit

____________________________________________________________________________

SUB-TEST: Especially people with several users logged in, or with multi-display setups, could you run this command:

w -hs

and post the result here? Thanks!

____________________________________________________________________________

WHY Pt.2: Head_on_a_Stick's post here got me thinking and googling about systemd services. Eventually I made a new service file /etc/systemd/system/notify-failure@.service:

[Unit]
Description=Send failure notification
[Service]
Type=oneshot
ExecStart=/usr/bin/notify-broadcast "Service Failed" "%I" --icon=dialog-error

This has to be called with some string, which will be passed on to notify-broadcast as a message, so any service can use it to report failure with an entry like this:

OnFailure=notify-failure@some_systemd_escaped_message_string.service

If you'd like to test that above systemd unit for me, assuming you already have /usr/bin/notify-broadcast working OK, copy that first block of code (starting with [Unit]) into /etc/systemd/system/notify-failure@.service (yes, that's a @ just before the dot). You can run it with:

sudo systemctl daemon-reload # get the new file recognized
sudo systemctl start notify-failure@test_message.service

The popup should appear with a title "Service Failed" and a message of "test_message". (test_message can be replaced with a long message string with spaces and newlines, but you must escape it first with 'systemd-escape'.)

Last edited by johnraff (2016-09-07 05:39:43)

Sector11 · 2016-09-02 12:37:12

So I thought why not.

1. Pasted the script into my text editor started as root and saved it to /usr/bin/notify-broadcast and chmodded it.

2. Opened a terminal

notify-broadcast --help # should output a short message, and exit 0

nothing happened ... cursor just blinking under the command - did not "exit"

opened another terminal:

notify-broadcast # should output an error message and exit 1

same result, except ... mouse pointer was 'jerky'

opened another terminal:

sudo notify-broadcast 'Title' 'Any message you like' --icon=dialog-error

added my password ... mouse 'froze' ... maybe 6 or 7 seconds later screen went black.
Had to restart computer ... nothing else worked!

Did not do this one:

sudo notify-broadcast ...any notify-send arguments you like...

johnraff · 2016-09-02 13:36:42

@Sector11 Thanks for checking this.
That's all most strange.

I just copied back the code into a new script notify-broadcast2 in case I'd made a c&p mistake, but it still seems OK.
Have you got libnotify-bin installed? What does 'which notify-send' report?
But anyway, the --help option should output a message and exit before even thinking about notify-send, which it does for me.

What do these commands return, if you don't mind risking a reboot...

which notify-broadcast
file /usr/bin/notify-broadcast
ls -l /usr/bin/notify-broadcast

EDIT: and, does the output of:

cat /usr/bin/notify-broadcast

look like the code I posted above?

Then, the riskier one:

bash -x /usr/bin/notify-broadcast

I got this:

john@bunsen1:~$ bash -x /usr/bin/notify-broadcast2
+ HELP='Call notify-send for all current X users.
Passed arguments are sent on as-is.
This script must be run as root.'
+ case $1 in
++ id -u
+ [[ 1000 -eq 0 ]]
+ error_exit 'This script must be run as root.'
+ echo '/usr/bin/notify-broadcast2 error: This script must be run as root.'
/usr/bin/notify-broadcast2 error: This script must be run as root.
+ exit 1

(notify-broadcast2 is my copied-back-from-the-forum version.)

Last edited by johnraff (2016-09-02 13:56:32)

Sector11 · 2016-09-02 14:57:55

Hello again ... here you go:

 02 Sep 16 @ 11:49:03 ~
  $ list libnotify-bin
Alias for: apt list -a filename
Listing... Done
libnotify-bin/stable,now 0.7.6-2 amd64 [installed]

 
 02 Sep 16 @ 11:49:20 ~
  $ which notify-broadcast
/usr/bin/notify-broadcast
 
 02 Sep 16 @ 11:49:25 ~
  $ file /usr/bin/notify-broadcast
/usr/bin/notify-broadcast: ASCII text
 
 02 Sep 16 @ 11:49:34 ~
  $ ls -l /usr/bin/notify-broadcast
-rwxr-xr-x 1 root root 303 Sep  2 08:42 /usr/bin/notify-broadcast
 
 02 Sep 16 @ 11:49:43 ~
  $ cat /usr/bin/notify-broadcast
notify-broadcast --help # should output a short message, and exit 0
notify-broadcast # should output an error message and exit 1
sudo notify-broadcast 'Title' 'Any message you like' --icon=dialog-error # or some other icon
sudo notify-broadcast ...any notify-send arguments you like... # all should work 
 02 Sep 16 @ 11:49:51 ~
  $

Now, I tried the "riskier one"

bash -x /usr/bin/notify-broadcast

Terminal did not return to the prompt, mouse/keyboard/everything locked up ... 10/15 seconds later "black screen" - only option: Reboot

And as I look at that I see a GLARING: OOPS! OH CRAP!
Gimme a sec .... OK, new start:

  $ cat /usr/bin/notify-broadcast
#!/bin/bash

HELP="Call notify-send for all current X users.
Passed arguments are sent on as-is.
This script must be run as root."

error_exit() {
    echo "$0 error: $1" >&2
    exit 1
}

case $1 in
--help|-h)
    echo "$HELP"
    exit
    ;;
esac

[[ $( id -u ) -eq 0 ]] || error_exit "This script must be run as root."

declare -A DISPLAYS
DISPLAYS=()

while read user tty from other
do
    [[ $from = :?* ]] || continue
    DISPLAYS["$user"]="$from"
done < <( w -hs )

for i in "${!DISPLAYS[@]}"; do
    sudo -u "$i" DISPLAY="${DISPLAYS[$i]}" notify-send "$@"
done

exit 
 02 Sep 16 @ 11:56:44 ~
  $

and now I'll try the riskier one ... but submit this first.

I'm such a noob!!! :8

Sector11 · 2016-09-02 15:03:48

I got this:

 02 Sep 16 @ 11:56:44 ~
  $ bash -x /usr/bin/notify-broadcast
+ HELP='Call notify-send for all current X users.
Passed arguments are sent on as-is.
This script must be run as root.'
+ case $1 in
++ id -u
+ [[ 1000 -eq 0 ]]
+ error_exit 'This script must be run as root.'
+ echo '/usr/bin/notify-broadcast error: This script must be run as root.'
/usr/bin/notify-broadcast error: This script must be run as root.
+ exit 1
 
 02 Sep 16 @ 11:59:47 ~
  $

I feel sooooooooooooooooo :8 8o :8

Sector11 · 2016-09-02 15:09:23

And I continue:

 02 Sep 16 @ 11:59:47 ~
  $ notify-broadcast --help
Call notify-send for all current X users.
Passed arguments are sent on as-is.
This script must be run as root.
 
 02 Sep 16 @ 12:01:52 ~
  $ notify-broadcast
/usr/bin/notify-broadcast error: This script must be run as root.
 
 02 Sep 16 @ 12:02:06 ~
  $ sudo notify-broadcast 'Title' 'I am a noob!' --icon=dialog-error
[sudo] password for sector11: 
 
 02 Sep 16 @ 12:02:49 ~
  $ sudo notify-broadcast 'Title' 'I am a NOOB!' --icon=dialog-error
 
 02 Sep 16 @ 12:03:26 ~
  $

and there it is:

Yea, that's better.

sudo notify-broadcast ...any notify-send arguments you like...

Didn't try the last one as I'm such a noob I have no idea what "arguments" to put in the command.

But there you go.

Now it's up to the more techy LabRats to answer 1, 2 and 3 for you.
Good Luck!

damo · 2016-09-02 19:01:10

Sector11 wrote:

sudo notify-broadcast ...any notify-send arguments you like...
Didn't try the last one as I'm such a noob I have no idea what "arguments" to put in the command.
...

Any command parameter (ie argument) that is allowed...

 $ notify-send --help
Usage:
  notify-send [OPTION...] <SUMMARY> [BODY] - create a notification

Help Options:
  -?, --help                        Show help options

Application Options:
  -u, --urgency=LEVEL               Specifies the urgency level (low, normal, critical).
  -t, --expire-time=TIME            Specifies the timeout in milliseconds at which to expire the notification.
  -a, --app-name=APP_NAME           Specifies the app name for the icon
  -i, --icon=ICON[,ICON...]         Specifies an icon filename or stock icon to display.
  -c, --category=TYPE[,TYPE...]     Specifies the notification category.
  -h, --hint=TYPE:NAME:VALUE        Specifies basic extra data to pass. Valid types are int, double, string and byte.
  -v, --version                     Version of the package.

Sector11 · 2016-09-02 19:39:23

Yes, well, in my defence - two things.
1. I'm_a_noob, and
2. I was in a rush as we had to get to the bank before it closed.

However:

 02 Sep 16 @ 16:32:48 ~
  $ notify-send --app-name=thunar Hi "I am Thor!"

I don't see any icon in there:

But at least I know when the techy-savy people get to it it will work

Last edited by Sector11 (2016-09-02 19:40:28)

Head_on_a_Stick · 2016-09-03 20:29:12

Tested from a virtually stock, almost fresh, updated BunsenLabs Hydrogen system running on the bare metal on an Intel Haswell i3-4330M/HD4600 laptop.

The first set of tests:

empty@TheLab:~$ notify-broadcast --help
Call notify-send for all current X users.
Passed arguments are sent on as-is.
This script must be run as root.
empty@TheLab:~$ echo $?
0
empty@TheLab:~$ notify-broadcast
/usr/bin/notify-broadcast error: This script must be run as root.
empty@TheLab:~$ echo $?
1
empty@TheLab:~$ sudo notify-broadcast 'Title' 'Any message you like' --icon=dialog-error
empty@TheLab:~$ echo $?
0
empty@TheLab:~$ sudo notify-broadcast -u critical 'HELP!' -t 100000
empty@TheLab:~$ echo $?
0
empty@TheLab:~$

All worked exactly as expected

For the systemd stuff:

empty@TheLab:~$ sudo systemctl daemon-reload
empty@TheLab:~$ sudo systemctl start notify-failure@test_message.service

Oh yeah

Good work John!

EDIT: Also:

empty@TheLab:~$ w -hs
empty    :0       :0               ?xdm?  /usr/bin/openbox --startup /usr/lib/x8
empty    pts/0    :0                2.00s w -hs

Last edited by Head_on_a_Stick (2016-09-03 20:31:29)

johnraff · 2016-09-05 02:37:44

Thanks to all.

It's looking OK so far, but I'm hoping it might work with more than one user logged in at more than one display (ie DISPLAY is not necessarily :0).

If anyone here has (or can temporarily set up) two separate X sessions with two different users on their system running simultaneously, I'd be overjoyed to hear that they both got the notification from root.

---

I think I'll post an "other" help post on the general background issues (if "w" is the best app to use, whether users should be [Active] to get messages, whether there's a better way to do this...).

Last edited by johnraff (2016-09-05 03:56:57)

Head_on_a_Stick · 2016-09-05 21:18:36

johnraff wrote:

If anyone here has (or can temporarily set up) two separate X sessions with two different users on their system running simultaneously, I'd be overjoyed to hear that they both got the notification from root.

Got four X sessions running but on my laptop (my only other screen is an old CRT television with SCART inputs) and everything works perfectly -- the notifications show up on *all* desktops.

empty@TheLab:~$ w -hs
test1    tty1                      10:48  xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :1 vt1 -auth /tmp/serverauth.UpVkYZT3hq
empty    :0       :0               ?xdm?  /usr/bin/openbox --startup /usr/lib/x86_64-linux-gnu/openbox-autostart OPENBOX
empty    pts/0    :0               11:05  /usr/bin/python /usr/bin/x-terminal-emulator
empty    pts/1    :0                3.00s w -hs
test2    pts/2    :2                2:59  /bin/bash
test1    pts/3    :1                5:49  /bin/bash
test2    tty2                       5:32  xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :2 vt2 -auth /tmp/serverauth.rdf8oEDieb
test3    pts/4    :3               25.00s /bin/bash
test3    tty3                       3:49  xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :3 vt3 -auth /tmp/serverauth.uZZX2R6QjM

EDIT: "test{1,2,3}" user's desktops initialised with `startx` (no ~/.xinitrc present).

Last edited by Head_on_a_Stick (2016-09-05 21:20:09)

johnraff · 2016-09-06 05:01:35

Major thanks HoaS that's great news!

If you still have that setup, or can get it together again easily, I wonder if I could ask one more favour?
Run this and post the output:

for i in $(loginctl --no-legend list-sessions | awk '{print $1}');do loginctl show-session -p Name -p Active -p Remote -p Type -p Display "$i";echo '-----';done

While 'w -hs' seems to be working fine, I'm wondering if systemd's utility loginctl might be a bit more reliable. That line's output should give us a good idea. I'm especially interested in which sessions are considered "active".

Head_on_a_Stick · 2016-09-06 06:22:05

Run from TTY7 (LightDM) with user "empty" (me):

empty@TheLab:~$ for i in $(loginctl --no-legend list-sessions | awk '{print $1}');do loginctl show-session -p Name -p Active -p Remote -p Type -p Display "$i";echo '-----';done
Name=lightdm
Display=:0
Remote=no
Type=x11
Active=no
-----
Name=empty
Display=:0
Remote=no
Type=x11
Active=yes
-----
Name=test1
Display=
Remote=no
Type=tty
Active=no
-----
Name=test2
Display=
Remote=no
Type=tty
Active=no
-----
Name=test3
Display=
Remote=no
Type=tty
Active=no
-----
empty@TheLab:~$

Run from TTY1 with user "test1" (with other TTYs following the same pattern):

test1@TheLab:~$ for i in $(loginctl --no-legend list-sessions | awk '{print $1}');do loginctl show-session -p Name -p Active -p Remote -p Type -p Display "$i";echo '-----';done
Name=lightdm
Display=:0
Remote=no
Type=x11
Active=no
-----
Name=empty
Display=:0
Remote=no
Type=x11
Active=no
-----
Name=test1
Display=
Remote=no
Type=tty
Active=yes
-----
Name=test2
Display=
Remote=no
Type=tty
Active=no
-----
Name=test3
Display=
Remote=no
Type=tty
Active=no
-----
test1@TheLab:~$

As an aside, is there a special trick for creating new users in BunsenLabs?

I tried adduser(8) but the BL skel directory was not used, I had to run this instead:

# useradd -m -k /usr/share/bunsen/skel -s /bin/bash -G sudo test1

johnraff · 2016-09-06 06:30:17

test{1,2,3} are tty sessions now, right? I guess that might be why they are marked as "Active=no".

I hate to put you to all this trouble, but I don't suppose you could get an X session running on at least one of the test users (as you had yesterday when the notification popups worked) and run that command again? I'm interested in whether all the X sessions are flagged as active.

Head_on_a_Stick · 2016-09-06 06:32:26

^ I had to cross edit the post from both desktops so it's probably updated for you by now

To clarify: I'm running this from my laptop (so only one DISPLAY) and the second code block was posted from an active X session on TTY1 under user "test1".

johnraff · 2016-09-06 06:35:36

Head_on_a_Stick wrote:

As an aside, is there a special trick for creating new users in BunsenLabs?
I tried adduser(8) but the BL skel directory was not used...

I use 'adduser username' then log into the new user via Lightdm. bl-user-setup gets run automatically. If you're not using a DM you can run /usr/lib/bunsen/configs/bl-user-setup from a tty before doing startx.

johnraff · 2016-09-06 06:42:52

Head_on_a_Stick wrote:

I'm running this from my laptop (so only one DISPLAY) and the second code block was posted from an active X session on TTY1 under user "test1".

This doesn't look like an X session to me:

Name=test1
Display=
Remote=no
Type=tty
Active=yes

No display and Type=tty.

As I said, only if you have the time, but if you could have two different users with X sessions running (as you did yesterday?) when you run that command, it would really help. (Of course, it doesn't have to be today though...)

Head_on_a_Stick · 2016-09-06 06:57:43

johnraff wrote:

could have two different users with X sessions running (as you did yesterday?) when you run that command, it would really help.

For all the code blocks posted today, there were four (4) active X sessions running.

johnraff · 2016-09-06 07:29:49

But only LightDm and empty have Type=x11 or Display=something.
Each of them was running on a separate display?

Could you try 'w -hs' again, please?

Head_on_a_Stick · 2016-09-06 08:22:09

johnraff wrote:

Each of them was running on a separate display?

Yes.

Could you try 'w -hs' again, please?

I will post again tonight, $DAY_JOB is calling...

#1 2016-09-02 07:49:51

[DONE] RFT: notify-broadcast

#2 2016-09-02 12:37:12

Re: [DONE] RFT: notify-broadcast

#3 2016-09-02 13:36:42

Re: [DONE] RFT: notify-broadcast

#4 2016-09-02 14:57:55

Re: [DONE] RFT: notify-broadcast

#5 2016-09-02 15:03:48

Re: [DONE] RFT: notify-broadcast

#6 2016-09-02 15:09:23

Re: [DONE] RFT: notify-broadcast

#7 2016-09-02 19:01:10

Re: [DONE] RFT: notify-broadcast

#8 2016-09-02 19:39:23

Re: [DONE] RFT: notify-broadcast

#9 2016-09-03 20:29:12

Re: [DONE] RFT: notify-broadcast

#10 2016-09-05 02:37:44

Re: [DONE] RFT: notify-broadcast

#11 2016-09-05 21:18:36

Re: [DONE] RFT: notify-broadcast

#12 2016-09-06 05:01:35

Re: [DONE] RFT: notify-broadcast

#13 2016-09-06 06:22:05

Re: [DONE] RFT: notify-broadcast

#14 2016-09-06 06:30:17

Re: [DONE] RFT: notify-broadcast

#15 2016-09-06 06:32:26

Re: [DONE] RFT: notify-broadcast

#16 2016-09-06 06:35:36

Re: [DONE] RFT: notify-broadcast

#17 2016-09-06 06:42:52

Re: [DONE] RFT: notify-broadcast

#18 2016-09-06 06:57:43

Re: [DONE] RFT: notify-broadcast

#19 2016-09-06 07:29:49

Re: [DONE] RFT: notify-broadcast

#20 2016-09-06 08:22:09

Re: [DONE] RFT: notify-broadcast

Board footer