You are not logged in.
Pages: 1
I'm trying to understand systemd better, and I created a simple test unit file:
test_debug.service
[Unit]
Description=Testing Systemd
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/touch /home/username/systemd_test
[Install]
WantedBy=default.target
I can get it to work as a system service but not as a user service. If I place the file in /etc/systemd/system/ and run
sudo systemctl enable --now test_debug.service
, then I can check my home directory, and I see that systemd_test exists. And systemctl status test_debug.service returns
● test_debug.service - Testing Systemd
Loaded: loaded (/etc/systemd/system/test_debug.service; enabled; preset: disabled)
Active: active (exited) since Thu 2024-11-21 12:41:22 CST; 2min 56s ago
Invocation: 1913a89878014081be246d18c34bd7c2
Process: 76952 ExecStart=/usr/bin/touch /home/username/systemd_test (code=exited, status=0/SUCCESS)
Main PID: 76952 (code=exited, status=0/SUCCESS)
Mem peak: 1.6M
CPU: 9ms
Nov 21 12:41:22 hostname systemd[1]: Starting Testing Systemd...
Nov 21 12:41:22 hostname systemd[1]: Finished Testing Systemd.
But if I then
sudo systemctl stop test_debug.service; sudo systemctl disable test_debug.service
and then move the file into /etc/systemd/user/ and run systemctl --user enable test_debug.service, I get
Failed to enable unit: Unit $HOME/.config/systemd/user/default.target.wants/test_debug.service does not exist
And if I do sudo systemctl --user enable test_debug.service, I get
Failed to connect to user scope bus via local transport: No medium found
(By the way, are you supposed to use sudo when enabling user services that are in /etc/systemd/user as opposed to ~/.config/systemd/user? Or do you not use sudo for either?)
What I understand from the wiki is that ~/.config/systemd/user/ is for user files that the user creates for themselves, and /etc/systemd/user is for files that the administer creates for all users to be able to enable/disable. So if I'm trying to place a unit file in /etc/systemd/user/, why is it looking for a file in ~/.config/systemd/user/default.target.wants/?
On the other hand, if I move the file to ~/.config/systemd/user and try to systemctl --user neable test_debug.service, then I get
Failed to enable unit: Unit test_debug.service does not exist
How do I (1) enable and start this service as a system-wide user service and (2) enable and start this service as a user-defined unit (i.e. in ~/.config/systemd/user)?
BTW, here's the permissions of the file:
-rw-r--r-- 1 root root 166 Nov 19 12:32 test_debug.service
Offline
You don't use sudo with user services unless you opt for the --global flag to enable it for all users. It's an user service you enable it as your user, if you sudo you're not your user anymore. It's looking for a file in your home dir because that's where it wants to make the symlink to signify you've enabled the unit for your user.
All of this works fine here $HOME/.config/systemd/user/default.target.wants/test_debug.service does not exist reads weird, why is $HOME not resolved? Unless that's some attempt to obfuscate your username, unless it's something obscene or completely unshareable please post the actual real output. This is likely down to either dbus or your home env being borked, what does
printenv
give for you.
Last edited by V1del (2024-11-21 22:56:34)
Offline
I replaced my username in all the outputs with "username", but the output of systemctl --user enable test_debug.service, which contains $HOME is verbatim.
The result of printenv | grep HOME is
XDG_CONFIG_HOME=/home/username/.config
HOME=/home/username
The full output of printenv is
SHELL=/usr/bin/zsh
HYPRLAND_CMD=Hyprland
XDG_BACKEND=wayland
CREDENTIALS_DIRECTORY=/run/credentials/getty@tty1.service
XDG_CONFIG_HOME=/home/username/.config
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
HL_INITIAL_WORKSPACE_TOKEN=cee6395f-7864-488b-9e98-5ebd2c50ddf5
XCURSOR_SIZE=24
XDG_SEAT=seat0
PWD=/home/username
LOGNAME=username
XDG_SESSION_TYPE=wayland
SYSTEMD_EXEC_PID=2489
_=/usr/bin/printenv
MOTD_SHOWN=pam
HOME=/home/username
LANG=en_US.UTF-8
_JAVA_AWT_WM_NONREPARENTING=1
XDG_CURRENT_DESKTOP=Hyprland
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/system.slice/system-getty.slice/getty@tty1.service/memory.pressure
WAYLAND_DISPLAY=wayland-1
INVOCATION_ID=8d80ab13678546829f649120f412c7eb
XDG_SESSION_CLASS=user
TERM=xterm-kitty
ZDOTDIR=/home/username/.config/zsh
USER=username
HYPRLAND_INSTANCE_SIGNATURE=12f9a0d0b93f691d4d9923716557154d74777b0a_1732237024_2103349620
DISPLAY=:0
SHLVL=2
MOZ_ENABLE_WAYLAND=1
XDG_VTNR=1
XDG_SESSION_ID=1
XDG_RUNTIME_DIR=/run/user/1000
DEBUGINFOD_URLS=https://debuginfod.archlinux.org
XDG_DATA_DIRS=/home/username/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/var/lib/flatpak/exports/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/username/Applications/swww/target/release
GDK_SCALE=1.5
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/username
OLDPWD=/home/username
HYPRCURSOR_SIZE=24
KITTY_WINDOW_ID=1
COLORTERM=truecolor
KITTY_PID=3175
KITTY_PUBLIC_KEY=1:_V`11)g@9b@P#kGQm7Q7%gKukQr<Jyh6}WAoiS-I
TERMINFO=/usr/lib/kitty/terminfo
KITTY_INSTALLATION_DIR=/usr/lib/kitty
ZSH=/home/username/.config/oh-my-zsh
PAGER=less
LESS=-R
LSCOLORS=Gxfxcxdxbxegedabagacad
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.7z=01;31:*.ace=01;31:*.alz=01;31:*.apk=01;31:*.arc=01;31:*.arj=01;31:*.bz=01;31:*.bz2=01;31:*.cab=01;31:*.cpio=01;31:*.crate=01;31:*.deb=01;31:*.drpm=01;31:*.dwm=01;31:*.dz=01;31:*.ear=01;31:*.egg=01;31:*.esd=01;31:*.gz=01;31:*.jar=01;31:*.lha=01;31:*.lrz=01;31:*.lz=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.lzo=01;31:*.pyz=01;31:*.rar=01;31:*.rpm=01;31:*.rz=01;31:*.sar=01;31:*.swm=01;31:*.t7z=01;31:*.tar=01;31:*.taz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tgz=01;31:*.tlz=01;31:*.txz=01;31:*.tz=01;31:*.tzo=01;31:*.tzst=01;31:*.udeb=01;31:*.war=01;31:*.whl=01;31:*.wim=01;31:*.xz=01;31:*.z=01;31:*.zip=01;31:*.zoo=01;31:*.zst=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.crdownload=00;90:*.dpkg-dist=00;90:*.dpkg-new=00;90:*.dpkg-old=00;90:*.dpkg-tmp=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:*.swp=00;90:*.tmp=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:
ZSH_COMPDUMP=/home/username/.config/oh-my-zsh/cache/.zcompdump-hostname
Furthermore, the result of systemctl --user show-environment is
HOME=/home/username
LANG=en_US.UTF-8
LOGNAME=username
MAIL=/var/spool/mail/username
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/var/lib/flatpak/exports/bin:/usr/bi>
SHELL=/usr/bin/zsh
USER=username
XDG_CONFIG_HOME=/home/username/.config
XDG_DATA_DIRS=/home/elliots/.local/share/flatpak/exports/share:/var/lib/flatpak/e>
XDG_RUNTIME_DIR=/run/user/1000
ZDOTDIR=/home/username/.config/zsh
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DISPLAY=:0
HYPRLAND_INSTANCE_SIGNATURE=12f9a0d0b93f691d4d9923716557154d74777b0a_1732237024_2>
WAYLAND_DISPLAY=wayland-1
XDG_CURRENT_DESKTOP=Hyprland
So when enabling a unit in /etc/systemd/user, it should create a link in /home/username/.config/systemd/user/whatever.target.wants/?
Offline
that all looks fine, does .config/systemd/user exist and what are the permissions along that path? stat each of those dirs, they all should be owned by your user.
Offline
Home:
➜ / ls -ld home
drwxr-xr-x 3 root root 4096 Nov 17 22:06 home
Username:
➜ /home ls -ld username
drwx------ 33 username username 4096 Nov 21 21:42 username
Config:
➜ ~ ls -ld .config
drwxr-xr-x 56 username username 4096 Nov 20 20:43 .config
Systemd:
➜ .config git:(main) ✗ ls -ld systemd
drwxr-xr-x 3 username username 4096 Aug 11 13:35 systemd
User:
➜ systemd git:(main) ✗ ls -ld user
drwxr-xr-x 5 username username 4096 Nov 21 15:34 user
Inside user folder
➜ user git:(main) ✗ ls -lA
total 12
drwxr-xr-x 2 username username 4096 Nov 19 08:16 default.target.wants
drwxr-xr-x 4 username username 4096 Nov 18 21:08 scripts
drwxr-xr-x 2 username username 4096 Nov 19 08:12 timers.target.wants
(Note the scripts folder is one I created to host scripts that my user services could run... after I figure out how to set up a user service at all)
And inside default.target.wants:
➜ default.target.wants git:(main) ✗ ls -lA
total 0
lrwxrwxrwx 1 username username 40 Aug 12 15:22 asusd-user.service -> /usr/lib/systemd/user/asusd-user.service
Note that the asusd-user.service is a service created by an installed package, and it works. But no user service files I create seem to be working.
Last edited by KhanGressman (2024-11-22 03:53:53)
Offline
ZSH=/home/username/.config/oh-my-zsh
I assume you're also using zsh as your login shell?
What if you change that to bash and/or comment OMZ in your zshrc or even better, remove it from your computer?
Edit: Also how do you start Hyprland?
Last edited by seth (2024-11-22 08:00:56)
Online
Wouldn't any incorrect hyprland start attempts already lead to failure to talk to the session bus? and DBUS_SESSION_BUS_ADDRESS looks sane.
Offline
It's more likely OMZ but the question is also whether and how zsh is involved in starting the session.
Online
Yes, I'm using oh-my-zsh. Is there some known issue with oh-my-zsh and systemd? I don't have any login manager installed, so I just log in on a TTY and run Hyprland to start Hyprland.
I tried switching my default shell to bash
$ chsh -s /bin/bash
Changing shell for username.
Password:
Shell changed.
I didn't do the homect thing from the Arch Wiki because I'm not using the systemd-homed:
$ systemctl status systemd-homed.service
○ systemd-homed.service - Home Area Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-homed.service; disabled; pre>
Drop-In: /usr/lib/systemd/system/systemd-homed.service.d
└─10-nvidia-no-freeze-session.conf
Active: inactive (dead)
Docs: man:systemd-homed.service(8)
man:org.freedesktop.home1(5)
All my zsh config files are in my .config folder, and I set env = ZSOTDIR,$HOME/.config/zsh in my hyprland.conf.
I renamed the oh-my-zsh to oh-my-zsh.old and zsh to zsh.old. Then I logged out and logged back in (I haven't restarted my computer yet, but the default shell is now bash, and when I run zsh, none of my configurations are loaded). However, I still get the same error from systemctl --user enable test_debug.service.
Last edited by KhanGressman (2024-11-22 19:00:16)
Offline
There're some known issues w/ OMZ. One in particular. It's sa train-wreck.
But apparently not at fault here.
Let's check the scope of the bogus $HOME expansion:
when I run zsh, none of my configurations are loaded). However, I still
Did you still attempt this from an zsh or from the bash?
Also, what's the output of
systemctl --user enable gnarf.service # I know that there's no gnarf.service, that's the point
I set env = ZSOTDIR,$HOME/.config/zsh in my hyprland.conf.
Literally "ZSOTDIR"?
Online
After changing my default shell to bash, I logged out and back in. Then I opened a terminal, which used bash by default, and I ran zsh. That was how I made sure my zsh configurations weren't still being loaded.
Oh, sorry, it was "ZDOTDIR". Typo.
It gives me a slightly different error with a service that doesn't exist:
$ systemctl --user enable gnarf.service
Failed to enable unit: Unit gnarf.service does not exist
So I suppose that means that it sees the file in /etc/systemd/user, but isn't able to create a link in $HOME/.config/systemd/user/default.target.wants/
Just now, I tried manually linking the unit file to ~/.config/systemd/user/default.target.wants:
$ ln -s /etc/systemd/user/test_debug.service ~/.config/systemd/user/default.target.wants/
$ ls -l ~/.config/systemd/user/default.target.wants/
total 0
lrwxrwxrwx 1 username username 40 Aug 12 15:22 asusd-user.service -> /usr/lib/systemd/user/asusd-user.service
lrwxrwxrwx 1 username username 36 Nov 22 19:01 test_debug.service -> /etc/systemd/user/test_debug.service
$ systemctl --user enable test_debug.service
Failed to enable unit: Unit $HOME/.config/systemd/user/default.target.wants/test_debug.service does not exist
$ systemctl --user status test_debug.service
× test_debug.service - Testing Systemd
Loaded: loaded (/etc/xdg/systemd/user/test_debug.service; disabled; preset: >
Active: failed (Result: exit-code) since Fri 2024-11-22 18:56:57 CST; 5min a>
Invocation: d0a54fb364a744e4a95dcb791a21c7ae
Process: 25782 ExecStart=/usr/bin/touch /home/username/systemd_test (code=exit>
Main PID: 25782 (code=exited, status=1/FAILURE)
Mem peak: 1.5M
CPU: 15ms
Nov 22 18:56:57 hostname systemd[2283]: Starting Testing Systemd...
Nov 22 18:56:57 hostname touch[25782]: /usr/bin/touch: cannot touch '/home>
Nov 22 18:56:57 hostname systemd[2283]: test_debug.service: Main process e>
Nov 22 18:56:57 hostname systemd[2283]: test_debug.service: Failed with re>
Nov 22 18:56:57 hostname systemd[2283]: Failed to start Testing Systemd.
Last edited by KhanGressman (2024-11-23 01:05:11)
Offline
I was playing around with systemd-analyze and found some things that may or may not be relevant.
$ systemd-analyze --user unit-files | grep test_debug
ids: test_debug.service → /etc/xdg/systemd/user/test_debug.service
aliases: test_debug.service ← test_debug.service
$ ls -l /etc/xdg/systemd/user
lrwxrwxrwx 1 root root 18 Nov 14 13:49 /etc/xdg/systemd/user -> ../../systemd/user
I don't know why there was a symlink in '/etc/xdg/systemd/user'. I removed the symlink from that folder, and then the result of the analyze command was:
$ systemd-analyze --user unit-files | grep test_debug
ids: test_debug.service → /etc/systemd/user/test_debug.service
aliases: test_debug.service ← test_debug.service
But still no luck trying to enable the service.
I also wanted to check if $HOME was being expanded in the list of unit paths:
$ systemd-analyze --user unit-paths
/home/username/.config/systemd/user.control
/run/user/1000/systemd/user.control
/run/user/1000/systemd/transient
/run/user/1000/systemd/generator.early
/home/username/.config/systemd/user
/etc/xdg/systemd/user
/etc/systemd/user
/run/user/1000/systemd/user
/run/systemd/user
/run/user/1000/systemd/generator
/home/username/.local/share/systemd/user
/home/username/.local/share/flatpak/exports/share/systemd/user
/var/lib/flatpak/exports/share/systemd/user
/usr/local/share/systemd/user
/usr/share/systemd/user
/usr/local/lib/systemd/user
/usr/lib/systemd/user
/run/user/1000/systemd/generator.late
So that seems to be working. But I suppose we already knew that it was locating the service just fine. It seems to be in creating the symlink where runs into problems. Is there a way to find out what directory it will try to put the symlink in given the Install target and whether it's a root service, or --user service, etc.?
For example, if my unit file has
[Install]
WantedBy=default.target
And if I enable it as --user, then it should create a symlink in /home/username/.config/systemd/user/default.target.wants/ (right?) Is there any way to check what folder it will try to put the file in? Maybe I could then see if there's any problem with expanding $HOME there.
Offline
Pages: 1