On 2019-10-12 at 09:25:20, Nikos Tsipinakis wrote: > This is usually caused by not having exported the DISPLAY variable into the > systemd environment, there has been extensive discussion about this in #347[1] > upstream. > > How are you starting X11, are you using a custom xinitrc?
I've got this line in my ~/.config/i3/config: exec --no-startup-id /home/francois/devel/remote/user-scripts/startup and that corresponds to a script [1] with these lines: /usr/bin/systemctl --user import-environment DISPLAY /usr/bin/systemctl status --user dunst I looked at both of the following bugs before switching [2] to the systemd service: https://github.com/dunst-project/dunst/issues/347 https://github.com/dunst-project/dunst/issues/611 > However it is weird that systemd reports that dunst is running even though it > obviously fails to start. I'm not sure what is going on there. I don't think it fails to start because it works fine and it looks like this: $ systemctl status --user dunst.service ● dunst.service - Dunst notification daemon Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-10-11 19:21:31 PDT; 15h ago Docs: man:dunst(1) Main PID: 5330 (dunst) Memory: 4.0M CGroup: /user.slice/user-1000.slice/user@1000.service/dunst.service └─5330 /usr/bin/dunst $ pgrep -a dunst 5330 /usr/bin/dunst The part that confuses me is that once a day (always almost exactly at the same time) it tries to start or restart (and fails) even though it's already running in my user session. Is there a cron-like job that runs every morning? Francois [1] https://github.com/fmarier/user-scripts/blob/master/startup [2] https://github.com/fmarier/user-scripts/commit/e8be9777cb7af012962408ba8f66ff19b13a485e -- https://fmarier.org/
