[Solved] Proper way to start system tasks (as opposed to applications)

screenfox · 2023-06-08 11:46:34

[Solved] It seems:
- .xsession overrides .xinitrc
- Always double check if you did chmod +x, i had forgotten that for the .xinitrc
- The .xinitrc copied from /etc/X11/xinit/xinitrc did solve the problem of dunst and xdg-desktop-portal-gtk not being started when needed after i correctly did chmod on it so it can be executed.
- The point above should be relevant for all packages that put a .service in /usr/lib/systemd/user/, at least if those are of the type

[Service]
Type=dbus

In conclusion, i no longer need to start certain services manually after i fixed my .xinitrc. The rest i have in my .xinitrc can stay there, i'd rather accept that than fight with xorg again.

Hi,

so i collected some fluff in my .xsession that i feel does not belong there. Applications go there, as it is me personally that wants to start them, but system components like dunst, xdg-desktop-portal-gtk and xset s off -dpms feel wrong here.

Is there a reasonably way to set these system tasks to start on login or am i expecting too much and just throwing all this stuff in my .xsession is how it is meant to be? Especially for dunst and xdg-desktop-portal-gtk i would have expected some kind of service to be managed by systemctl, but there are none.

Last edited by screenfox (2023-06-08 15:50:32)

hcjl · 2023-06-08 11:52:31

There is a pretty good overview in the wiki -> https://wiki.archlinux.org/title/Autostarting

V1del · 2023-06-08 11:57:53

screenfox wrote:

Especially for dunst and xdg-desktop-portal-gtk i would have expected some kind of service to be managed by systemctl, but there are none.

There are, for both of them, as user services, like they should be /usr/lib/systemd/user/xdg-desktop-portal-gtk.service and /usr/lib/systemd/user/dunst.service

If you've never seen those and don't know what user services are, see https://wiki.archlinux.org/title/Systemd/User and if you use startx you need to ensure there are some necessary imports getting done so that the user session is set up properly: https://wiki.archlinux.org/title/Xinit#xinitrc

Trilby · 2023-06-08 11:58:17

screenfox wrote:

Especially for dunst and xdg-desktop-portal-gtk i would have expected some kind of service to be managed by systemctl, but there are none.

What do you mean there are none? Each of those packages does provide their own service file.

(edit: too slow)

Last edited by Trilby (2023-06-08 12:00:24)

screenfox · 2023-06-08 12:21:35

V1del wrote:

There are, for both of them, as user services, like they should be /usr/lib/systemd/user/xdg-desktop-portal-gtk.service and /usr/lib/systemd/user/dunst.service

Thank you very much, i found them now. What i do not understand is how i can find out how to start them:

[user@DOMAIN ~]$ systemctl --user enable dunst.service 
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
[user@DOMAIN ~]$ systemctl --user enable xdg-desktop-portal-gtk.service
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.
 
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

So they do exist, but are not meant to be started?

the portal service for example:

[Unit]
Description=Portal service (GTK/GNOME implementation)

[Service]
Type=dbus
BusName=org.freedesktop.impl.portal.desktop.gtk
ExecStart=/usr/lib/xdg-desktop-portal-gtk

It kind of looks like it is meant to be started by D-Bus (dunst.service also has that line), but that does not happen? Maybe my fluxbox is missing some stuff here? I did copy /etc/X11/xinit/xinitrc to my user folder, so that should not be it.

Trilby · 2023-06-08 12:58:02

They both should be started via dbus if your session is properly configured (though according to the wiki, the dunst authors encourage manually starting it anyways)

screenfox wrote:

I did copy /etc/X11/xinit/xinitrc to my user folder, so that should not be it.

That sounds fishy. You shouldn't just copy it. Are you even using startx/xinit? Previously you mentioned an .xsession file which would suggest you are using a DM, right? Which one?

screenfox · 2023-06-08 13:26:45

Trilby wrote:

That sounds fishy. You shouldn't just copy it. Are you even using startx/xinit? Previously you mentioned an .xsession file which would suggest you are using a DM, right? Which one?

Sorry for not including these details. I use XDM to login directly to fluxbox.
In the provided .xinitrc that i copied, i commented out the xterm stuff and added exec startfluxbox. When i tried to autostart stuff, .xsession worked, so i didn't question it, but now that i am answering about my setup i see that something must be messed up if stuff in .xinirtc does not work...

I can only guess that after a heavy fight with the xserver to accept my graphics cards, i kinda just put stuff where it worked.

And now i feel dumb because i noticed the .xinitrc does not have a +x flag. Will check back and put solved when i had the time to reboot and test.

My complete .xsession

#!/bin/bash

setxkbmap de
xrdb .Xresources

.screenlayout/./active
xset s off -dpms
dunst &
/usr/lib/xdg-desktop-portal-gtk &

exec startfluxbox

My complete .xinitrc

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

# merge in defaults and keymaps

if [ -f $sysresources ]; then







    xrdb -merge $sysresources

fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then







    xrdb -merge "$userresources"

fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

# start some nice programs

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
 for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
  [ -x "$f" ] && . "$f"
 done
 unset f
fi

#twm &
#xclock -geometry 50x50-1+1 &
#xterm -geometry 80x50+494+51 &
#xterm -geometry 80x20+494-0 &

#.screenlayout/./active
#sleep 2
#/home/voller/.screenlayout/./active

#xrandr --output VGA-0 --off --output DVI-D-0 --mode 1920x1080 --pos 1920x0 --rotate normal --output HDMI-0 --mode 1920x1080 --pos 0x0 --rotate normal

# noch nicht versucht:
#[ -f /etc/xprofile ] && . /etc/xprofile
#[ -f ~/.xprofile ] && . ~/.xprofile

exec startfluxbox
# xterm -geometry 80x66+0+0 -name login

Trilby · 2023-06-08 13:30:24

If you are using xdm, your xinitrc is irrelevant. I have no idea how / if xdm is supposed to set up the session for you, but it is failing to do so (no suprise, DMs serve no purpose other than to break things).

You could move the xinitrc template content into your .xsession, though I have no idea if this is the recommended way to use xdm.

seth · 2023-06-08 14:16:57

Trilby wrote:

If you are using xdm, your xinitrc is irrelevant.

The default xdm xsession script actually runs the users xinitrc.
But oc. screenfox provides their own xsession script, so that takes precedence here.

You could move the xinitrc template content into your .xsession, though I have no idea if this is the recommended way to use xdm.

Explicitly importing the session environment should™ not be necessary w/ XDM

@screenfox, please post the outputs of

loginctl session-status
echo $DBUS_SESSION_BUS_ADDRESS

/usr/lib/systemd/user/dunst.service is dbus activated, so you cannot enable that.
Explicitly starting dunst is a good idea/necessary if you've other stuff that can provide the org.freedesktop.Notifications dbus service.
Otherwise w/o doing anything

pgrep dunst # no output
dunstify foo # gets you a notification and
pgrep dunst # shows the dunst PID

screenfox · 2023-06-08 15:41:20

seth wrote:

Explicitly importing the session environment should™ not be necessary w/ XDM
@screenfox, please post the outputs of
loginctl session-status
echo $DBUS_SESSION_BUS_ADDRESS

Thank you for the complete writeup, i corrected my chmod +x omission and moved the .xsession content to my .xinitrc, after a reboot this is the output:

[user@DOMAIN ~]$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/run/user/1000/bus
[user@DOMAIN ~]$ loginctl session-status
1 - user (1000)
           Since: Thu 2023-06-08 17:10:35 CEST; 29s ago
          Leader: 815 (xdm)
            Seat: seat0; vc2
             TTY: console
         Service: xdm; type x11; class user
           State: active
            Unit: session-1.scope
                  ├─ 815 "-:0                   "
                  ├─ 928 fluxbox
                  ├─1002 xterm
                  ├─1004 bash
                  ├─1006 loginctl session-status
                  └─1007 less

I tested the relevant things and am sure the .xinitrc was executed now. For example dunst is running since my volume up/down keys display the messages.

seth wrote:

/usr/lib/systemd/user/dunst.service is dbus activated, so you cannot enable that.
Explicitly starting dunst is a good idea/necessary if you've other stuff that can provide the org.freedesktop.Notifications dbus service.
Otherwise w/o doing anything
pgrep dunst # no output
dunstify foo # gets you a notification and
pgrep dunst # shows the dunst PID

Since i did no longer start dunst manually in my new .xinitrc, it seems this worked completely. I did get a pid, but i already used an application that did a dunst notification, so that must have started it. The xdg-desktop-portal-gtk also seems to be running, judging by my applications that hang without starting up immediately.

Thank you very much, i will try to summarize what is important to noobs like me in the [Solved] i will put in the original post.

Arch Linux

#1 2023-06-08 11:46:34

[Solved] Proper way to start system tasks (as opposed to applications)

#2 2023-06-08 11:52:31

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#3 2023-06-08 11:57:53

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#4 2023-06-08 11:58:17

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#5 2023-06-08 12:21:35

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#6 2023-06-08 12:58:02

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#7 2023-06-08 13:26:45

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#8 2023-06-08 13:30:24

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#9 2023-06-08 14:16:57

Re: [Solved] Proper way to start system tasks (as opposed to applications)

#10 2023-06-08 15:41:20

Re: [Solved] Proper way to start system tasks (as opposed to applications)

Board footer