SSD trim periodic with systemctl

 systemctl start   fstrim.service

thats executes as espected,

But to make it periodic:

systemctl enable  fstrim.timer
Failed to enable unit: File /etc/systemd/system/timers.target.wants/fstrim.timer: Not a directory

All this see information in:

Section periodic trim

How to proceed?

Seems to be a problem related to pamac IIRC, see Can't enable fstrim, systemctl fails

Please type the following in a terminal and give the output.

ls -l /etc/systemd/system

I am suspecting that timers.target.wants is actually a symbolic link pointing to a timer unit file instead of being a directory (or being non-existent at all).

1 Like

result is:

nsgesamt 32
drwxr-xr-x 2 root root 4096  3. Nov 2017  bluetooth.target.wants
lrwxrwxrwx 1 root root   41  3. Nov 2017  dbus-org.bluez.service -> /usr/lib/systemd/system/bluetooth.service
lrwxrwxrwx 1 root root   44  3. Nov 2017  dbus-org.freedesktop.Avahi.service -> /usr/lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root   44  3. Nov 2017  dbus-org.freedesktop.ModemManager1.service -> /usr/lib/systemd/system/ModemManager.service
lrwxrwxrwx 1 root root   46  3. Nov 2017  dbus-org.freedesktop.NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx 1 root root   57  3. Nov 2017  dbus-org.freedesktop.nm-dispatcher.service -> /usr/lib/systemd/system/NetworkManager-dispatcher.service
lrwxrwxrwx 1 root root   49 29. Okt 2018  dbus-org.freedesktop.timesync1.service -> /usr/lib/systemd/system/systemd-timesyncd.service
lrwxrwxrwx 1 root root   39  3. Nov 2017  display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x 2 root root 4096 26. Okt 2017  getty.target.wants
drwxr-xr-x 2 root root 4096 21. Jul 16:00 multi-user.target.wants
drwxr-xr-x 2 root root 4096  3. Nov 2017  printer.target.wants
drwxr-xr-x 2 root root 4096  3. Nov 2017  sleep.target.wants
drwxr-xr-x 2 root root 4096 10. Sep 2018  sockets.target.wants
drwxr-xr-x 2 root root 4096  6. Nov 2017  sysinit.target.wants
lrwxrwxrwx 1 root root   46 21. Jul 16:00 timers.target.wants -> /usr/lib/systemd/system/pamac-mirrorlist.timer
-rw-r--r-- 1 root root  241 10. Sep 2018  var-lib-snapd-snap-core-5328.mount

Manjaro stable XFCE

OS: Manjaro 18.0.4 Illyria
Kernel: x86_64 Linux 5.2.1-1-MANJARO
Uptime: 3h 24m
Packages: 1409
Shell: bash 5.0.7
Resolution: 1920x1080
DE: Xfce4
WM: Xfwm4
WM Theme:
Font: Not Identified
CPU: Intel Core i5-6400 @ 4x 3.3GHz [35.0°C]
GPU: GeForce GTX 1050 Ti
RAM: 1485MiB / 15986MiB

My noob solution could be:
/etc/cron.weekly -> systemctl start fstrim.service

Ok, you have been victim of a f- up made by Manjaro when they moved symlinks created to enable timer units to the right place. When you got pamac-common 8.0.3-4, instead of creating the symbolic links inside timers.target.wants, if you didn't already have the timers.target.wants directory, it actually created a symbolic link literally called timers.target.wants inside /etc/systemd/system pointing to a timer unit file. That is why when you try to enable a unit with WantedBy=timers.target, it fails to do so.

You will need to remove this symbolic link, then create the folder again, then manually enable various timer units you need/want to have.

Do the following commands in order to be able to enable units with WantedBy=timers.target properly.

sudo rm /etc/systemd/system/timers.target.wants
sudo mkdir /etc/systemd/system/timers.target.wants

After that, you should be able to enable fstrim.timer, pamac-mirrorlist.timer, pamac-cleancache.timer, etc. I use --now so the unit get started immediately (it is the equivalent of doing systemctl start right after systemctl enable).

systemctl enable --now fstrim.timer

(Replace fstrim.timer with any unit you want to enable (and start immediately).)

Sorry for the inconvenience. Hope the repair will go well.

EDIT: Typo and fix my explanation because it was totally wrong. Thanks @korealinux .

5 Likes

I installed 8.0.3-4 and this did not happen to me. Did it only happen on new installs?

ln -sf will create new symlinks or overwrite files as symlinks, but it will not overwrite directories. If the destination/directory is already present, ln -sf will add the symlink to the directory. So if timers.target.wants was already present, the bug did not trigger.

The packaging changed locations from multi-user.target.wants to timers.target.wants. On new installs, probably multi-user.target.wants is already present so there was never a problem before. But timers.target.wants does not exist, so it created a directory as a symlink.

So this caused a major error, but the actual changes itself look very innocent enough.

Thanks a lot Frog:

I removed the backslash at the end of:
sudo rm /etc/systemd/system/timers.target.wants"/"

Thats what i did, step by step:

[john1@manjaro ~]$ sudo rm /etc/systemd/system/timers.target.wants/
[sudo] Passwort für john1:
rm: das Entfernen von '/etc/systemd/system/timers.target.wants/' ist nicht möglich: Ist kein Verzeichnis
[john1@manjaro ~]$ sudo mkdir /etc/systemd/system/timers.target.wants
mkdir: das Verzeichnis „/etc/systemd/system/timers.target.wants“ kann nicht angelegt werden: Die Datei existiert bereits
[john1@manjaro ~]$ sudo rm /etc/systemd/system/timers.target.wants
[john1@manjaro ~]$ sudo mkdir /etc/systemd/system/timers.target.wants
[john1@manjaro ~]$ sudo systemctl enable --now fstrim.timer
Created symlink /etc/systemd/system/timers.target.wants/fstrim.timer → /usr/lib/systemd/system/fstrim.timer.
[john1@manjaro ~]$ sudo systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: disabled)
Active: active (waiting) since Thu 2019-07-25 11:17:41 CEST; 55s ago
Trigger: Mon 2019-07-29 00:00:00 CEST; 3 days left
Docs: man:fstrim

Jul 25 11:17:41 manjaro systemd[1]: Started Discard unused blocks once a week.

I think that looks good and i rm /etc/cron.monthly/fstrim.sh

My bad, it was a typo. I modified my previous post.

Glad it helped.

It could have happened on update too.

You're right, my first explanation was totally wrong. I'll change it.

If you already had timers.target.wants folder, you were indeed fine.

This could have been prevented by always using a trailing / if a directory is meant:

$ ln -sf ... $target/

That way an error about a missing $target-directory would pop up at the appropriate place: the one who wants to activate pamac-mirrorlist.timer

ln: failed to create symbolic link '$target/': No such file or directory
1 Like

It is an issue with pamac - which overwrites the folder when creating a link to the mirrorlist timer (my guess is it is using the --force argument - which is huge mistake)

sudo rm -f /etc/systemd/system/timers.target.wants

Then create the folder

sudo mkdir /etc/systemd/system/timers.target.wants

Then it works

sudo systemctl enable fstrim.timer

ln -sf doesn't overwrite directories with a symlink, even if the directory is empty, even with elevated privileges by calling sudo and even if the user using the command is the root user (UID 0).

Demo

[awesome@i56400 ~]$ mkdir demo
[awesome@i56400 ~]$ cd demo
[awesome@i56400 demo]$ ls -l
total 0
[awesome@i56400 demo]$ mkdir emptydir
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:29 emptydir
[awesome@i56400 demo]$ cd emptydir/
[awesome@i56400 emptydir]$ ls -l
total 0
[awesome@i56400 emptydir]$ cd ..
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:29 emptydir
[awesome@i56400 demo]$ ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:30 emptydir
[awesome@i56400 demo]$ cd emptydir/
[awesome@i56400 emptydir]$ ls -l
total 0
lrwxrwxrwx 1 awesome awesome 46 Jul 29 23:30 pamac-cleancache.timer -> /usr/lib/systemd/system/pamac-cleancache.timer
[awesome@i56400 emptydir]$ cd ..
[awesome@i56400 demo]$ sudo ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[sudo] password for awesome:
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:30 emptydir
[awesome@i56400 demo]$ cd emptydir/
[awesome@i56400 emptydir]$ ls -l
total 0
lrwxrwxrwx 1 root root 46 Jul 29 23:30 pamac-cleancache.timer -> /usr/lib/systemd/system/pamac-cleancache.timer
[awesome@i56400 emptydir]$ sudo rm pamac-cleancache.timer
[awesome@i56400 emptydir]$ ls -l
total 0
[awesome@i56400 emptydir]$ cd ..
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:31 emptydir
[awesome@i56400 demo]$ sudo ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:31 emptydir
[awesome@i56400 demo]$ cd emptydir
[awesome@i56400 emptydir]$ ls -l
total 0
lrwxrwxrwx 1 root root 46 Jul 29 23:31 pamac-cleancache.timer -> /usr/lib/systemd/system/pamac-cleancache.timer
[awesome@i56400 emptydir]$ sudo rm pamac-cleancache.timer
[awesome@i56400 emptydir]$ ls -l
total 0
[awesome@i56400 emptydir]$ cd ..
[awesome@i56400 demo]$ ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:31 emptydir
[awesome@i56400 demo]$ rm emptydir/
rm: cannot remove 'emptydir/': Is a directory
[awesome@i56400 demo]$ rmdir emptydir
[awesome@i56400 demo]$ ls -l
total 0
[awesome@i56400 demo]$ ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[awesome@i56400 demo]$ ls -l
total 0
lrwxrwxrwx 1 awesome awesome 46 Jul 29 23:32 emptydir -> /usr/lib/systemd/system/pamac-cleancache.timer
[awesome@i56400 demo]$ rm emptydir
[awesome@i56400 demo]$ sudo ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[awesome@i56400 demo]$ ls -l
total 0
lrwxrwxrwx 1 root root 46 Jul 29 23:32 emptydir -> /usr/lib/systemd/system/pamac-cleancache.timer
[awesome@i56400 demo]$ sudo rm emptydir
[awesome@i56400 demo]$ mkdir emptydir
[awesome@i56400 demo]$ su
Password:
[i56400 demo]# ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:34 emptydir
[i56400 demo]# ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[i56400 demo]# ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:34 emptydir
[i56400 demo]# cd emptydir
[i56400 emptydir]# ls -l
total 0
lrwxrwxrwx 1 root root 46 Jul 29 23:34 pamac-cleancache.timer -> /usr/lib/systemd/system/pamac-cleancache.timer
[i56400 emptydir]# rm pamac-cleancache.timer
[i56400 emptydir]# ls -l
total 0
[i56400 emptydir]# cd ..
[i56400 demo]# ls -l
total 4
drwxr-xr-x 2 awesome awesome 4096 Jul 29 23:35 emptydir
[i56400 demo]# rmdir emptydir/
[i56400 demo]# ls -l
total 0
[i56400 demo]# ln -sf /usr/lib/systemd/system/pamac-cleancache.timer /home/awesome/demo/emptydir
[i56400 demo]# ls -l
total 0
lrwxrwxrwx 1 root root 46 Jul 29 23:35 emptydir -> /usr/lib/systemd/system/pamac-cleancache.timer
[i56400 demo]# rm emptydir
[i56400 demo]# ls -l
total 0
[i56400 demo]# id
uid=0(root) gid=0(root) groups=0(root)
[i56400 demo]# exit
exit
[awesome@i56400 demo]$ id
uid=1000(awesome) gid=1000(awesome) groups=1000(awesome),3(sys),90(network),98(power),108(vboxusers),150(wireshark),619(autologin),988(storage),991(lp),998(wheel)
[awesome@i56400 demo]$

The most plausible explanation is that timers.target.wants was simply not there on his system before the symlink got created. On one of my Manjaro installation, I also didn't have this folder before I upgraded the pamac-common package to 8.0.3-5 (I skipped the faulty one).

The initial command used with 8.0.3-4 does create the wanted symlinks when the folder exists. But in this case, we couldn't assume that the folder actually existed.

I also though that the folder got overwritten (see my original explanation) initially, but @korealinux did notice that I was wrong. Fortunately, ln -s is not that destructive, even with the -f option!

1 Like

@Frog
Thank you for the clarification.

I did not check if a symlink could overwrite an existing folder using the --force argument.

I had exactly the same issue so I assumed it was possible as the folder existed on my system as a symlink to the pamac timer.

When I checked the installer code it had the ln -sf ... which I understood as a verification of the possibility so I didn't do a hard check on the command.

This topic was automatically closed after 180 days. New replies are no longer allowed.

Forum kindly sponsored by