You are not logged in.
I've been having an issue for a while with systemd-tmpfiles-clean.service taking a very long time to run. I've tried to just ignore it, but it's really bothering me now.
Measuring by running:
# time systemd-tmpfiles --clean
systemd-tmpfiles --clean 11.63s user 110.37s system 10% cpu 19:00.67 total
I don't seem to have anything funky in any tmpfiles.d:
# ls /usr/lib/tmpfiles.d/* /run/tmpfiles.d/* /etc/tmpfiles.d/* | pacman -Qo -
ls: cannot access /etc/tmpfiles.d/*: No such file or directory
error: No package owns /run/tmpfiles.d/kmod.conf
/usr/lib/tmpfiles.d/gvfsd-fuse-tmpfiles.conf is owned by gvfs 1.20.1-2
/usr/lib/tmpfiles.d/lastlog.conf is owned by shadow 4.1.5.1-9
/usr/lib/tmpfiles.d/legacy.conf is owned by systemd 212-3
/usr/lib/tmpfiles.d/libvirt.conf is owned by libvirt 1.2.4-1
/usr/lib/tmpfiles.d/lighttpd.conf is owned by lighttpd 1.4.35-1
/usr/lib/tmpfiles.d/lirc.conf is owned by lirc-utils 1:0.9.0-71
/usr/lib/tmpfiles.d/mkinitcpio.conf is owned by mkinitcpio 17-1
/usr/lib/tmpfiles.d/nscd.conf is owned by glibc 2.19-4
/usr/lib/tmpfiles.d/postgresql.conf is owned by postgresql 9.3.4-1
/usr/lib/tmpfiles.d/samba.conf is owned by samba 4.1.7-1
/usr/lib/tmpfiles.d/slapd.conf is owned by openldap 2.4.39-1
/usr/lib/tmpfiles.d/sudo.conf is owned by sudo 1.8.10.p2-1
/usr/lib/tmpfiles.d/svnserve.conf is owned by subversion 1.8.8-1
/usr/lib/tmpfiles.d/systemd.conf is owned by systemd 212-3
/usr/lib/tmpfiles.d/systemd-nologin.conf is owned by systemd 212-3
/usr/lib/tmpfiles.d/tmp.conf is owned by systemd 212-3
/usr/lib/tmpfiles.d/uuidd.conf is owned by util-linux 2.24.1-6
/usr/lib/tmpfiles.d/x11.conf is owned by systemd 212-3
How do I debug why it is taking so long? I've looked in man 8 systemd-tmpfiles and on google, hoping to find some sort of --dubug option, but there seems to be none.
Is it some how possible to get a list of the directories that it looks at when it runs?
Anyone have any suggestions on how else to fix this.
Anyone else have this issue?
Thanks,
Gary
Last edited by garyvdm (2014-05-08 18:57:43)
Offline
every systemd binary understands the SYSTEMD_LOG_LEVEL environment variable. You can set this to 'debug' and see what it's doing.
Short of that, strace is always an option.
Last edited by falconindy (2014-05-07 22:50:58)
Offline
Thank you very much falconindy. SYSTEMD_LOG_LEVEL=debug helped my find my issue.
The cause of the problem was thousands of directories in /var/tmp/ created by a test suite with a broken clean up method. systemd-tmpfiles-clean was recursing through these, but not deleting them.
Offline