From: Cron Daemon <email@example.com> To: firstname.lastname@example.org Subject: Cron <root@an-test-client1001> for user in $(ls /srv/home); do rm -rf /srv/home/$user/.local/share/Trash/*; done Date: Sun, 11 Jul 2021 00:00:01 +0000 X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/root> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=root> Message-Id: <E1m2Mt7-0006Yyemail@example.com> Date: Sun, 11 Jul 2021 00:00:01 +0000 ls: cannot access '/srv/home': No such file or directory
|operations/puppet||production||+9 -0||analytics: Migrate clean_jupyter_user_local_trash to systemd timer|
But I'm not sure migrating it to a timer fixes the underlying issue, which is that sometimes(?) /srv/home is missing.
I think it's just this single host an-test-client1001 that's sending this daily logspam now, isn't it?
To me, the issue looks like we should just be setting up /home as a symlink to /srv/home on this box, like we do on all of the other analytics-client (stat100[4-8]) boxes.
btullis@an-test-client1001:~$ ls -ld /home drwxr-xr-x 240 root root 4096 Aug 3 15:26 /home
btullis@stat1008:~$ ls -ld /home lrwxrwxrwx 1 root root 9 Mar 12 2020 /home -> /srv/home
I've been searching through puppet, but I can't seem to find where this symlink is configured. Once I find it, we can add an-test-client1001.eqiad.wmnet to the list and rebuild it, or point /home to /srv/home manually.
OK, in that case I've done the following to clear this bit of cron spam temporarily.
btullis@an-test-client1001:~$ ls -l /srv/home ls: cannot access '/srv/home': No such file or directory btullis@an-test-client1001:~$ sudo mkdir /srv/home btullis@an-test-client1001:~$ ls -ld /srv/home drwxr-xr-x 2 root root 4096 Aug 25 11:09 /srv/home
We could decide to move /home to /srv/home at another time, but this should stop the emails I think.