1

I have the following Python script:

# /path/to/__main.py__

[..]

subprocess.call("DISPLAY=:0 dbus-launch /usr/bin/notify-send -i dialog-information \'foo\' \'bar\'", shell=True)

[..]

and the following .service file:

# /etc/systemd/system/notification.service

[Unit]
Description=Notification service

[Service]

# Run permission service
ExecStart=/usr/bin/python3 /path/to/__main__.py

# keep process after user logs off
RemainAfterExit=false

[Install]
WantedBy=default.target

When I call /usr/bin/python3 /path/to/__main__.py in my terminal, the pop-up appears and there is no freeze or anything.

However, when I call sudo systemctl restart notification.service, the system (UI) freezes for ~20s (no interactions possible in UI), then the pop-up appears.

The question is: Why does this problem occur only when the script is called via systemd service?


Further outputs (maybe helpful for investigation)

This is the output of sudo systemctl status notification.service:

user@host:~$ sudo systemctl status notification.service 
● notification.service - Notification service
   Loaded: loaded (/etc/systemd/system/notification.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-12-13 11:54:37 +08; 1h 41min ago
  Process: 18420 ExecStartPre=/bin/bash -c test $(/usr/bin/id -u) -eq 0 (code=exited, status=0/SUCCESS)
 Main PID: 18433 (python3)
    Tasks: 25 (limit: 4915)
   CGroup: /system.slicenotification.service
           ├─18433 /usr/bin/python3 /path/to/__main__.py
           ├─18583 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
           ├─18588 /usr/lib/x86_64-linux-gnu/notify-osd
           ├─18715 /usr/lib/gvfs/gvfsd
           ├─18822 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
           ├─18827 /usr/lib/x86_64-linux-gnu/notify-osd
           ├─18990 /usr/lib/gvfs/gvfsd
           ├─19055 /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
           ├─19059 /usr/lib/x86_64-linux-gnu/notify-osd
           └─19222 /usr/lib/gvfs/gvfsd

Dec 13 11:55:34 host notify-osd[18827]: dnd_is_screensaver_active(): Got error "The name org.gnome.ScreenSaver was not provided by any .service files"
Dec 13 11:55:34 host notify-osd[18827]: dnd_is_idle_inhibited(): got error "The name org.gnome.SessionManager was not provided by any .service files"
Dec 13 11:55:43 host dbus-daemon[19055]: [session uid=0 pid=19053] AppArmor D-Bus mediation is enabled
Dec 13 11:55:43 host dbus-daemon[19055]: [session uid=0 pid=19053] Activating service name='org.freedesktop.Notifications' requested by ':1.0' (uid=0 pid=19001 comm="/usr/bin/notify-send -i dialog-information UpdateR" label="unconfined")
Dec 13 11:56:01 host dbus-daemon[19055]: [session uid=0 pid=19053] Activating service name='org.gtk.vfs.Daemon' requested by ':1.1' (uid=0 pid=19059 comm="/usr/lib/x86_64-linux-gnu/notify-osd " label="unconfined")
Dec 13 11:56:01 host dbus-daemon[19055]: [session uid=0 pid=19053] Successfully activated service 'org.gtk.vfs.Daemon'
Dec 13 11:56:01 host org.gtk.vfs.Daemon[19055]: fuse: bad mount point `/root/.gvfs': Transport endpoint is not connected
Dec 13 11:56:01 host dbus-daemon[19055]: [session uid=0 pid=19053] Successfully activated service 'org.freedesktop.Notifications'
Dec 13 11:56:01 host notify-osd[19059]: dnd_is_screensaver_active(): Got error "The name org.gnome.ScreenSaver was not provided by any .service files"
Dec 13 11:56:01 host notify-osd[19059]: dnd_is_idle_inhibited(): got error "The name org.gnome.SessionManager was not provided by any .service files"
lines 1-28/28 (END)

4
  • Does systemctl status notification show anything? Can you try running it as a user service instead? Dec 13, 2019 at 5:19
  • Yes, good hint. I added the output the question. I can't run it as a user service, as the service actually does some system-level changes (I removed that from my question, as it does not contribute to the problem, I guess).
    – SilverJan
    Dec 13, 2019 at 5:37
  • I ran into similar problems with scripts run out of root's crontab. I'd bet that running it as a user service will solve your problem. Dec 13, 2019 at 5:44
  • The problem is that I need to run it as a system service due to the above mentioned reason..
    – SilverJan
    Dec 13, 2019 at 5:53

1 Answer 1

1

OK, here's what I did to fix this problem when running scripts out of root's crontab. I'm still learning python, so you'll need to convert this info as required.

First, I added xhost authority for root to my .bashrc:

xhost + SI:localuser:root > /dev/null

Second, I added the following variables to root's crontab:

DISPLAY=":0.0"
XAUTHORITY="/home/me/.Xauthority"
XDG_RUNTIME_DIR="/run/user/1000"
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

Third, I ran each notify-send as me, something like this:

su me -c '/usr/bin/notify-send "Weekly backup started - $(date +%Y-%m-%d) @ $(date +%H:%M:%S)"'

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .