Problem with cron (I think)

English Applications
1

On my computer, I have a directory called /mnt/NAS-Backup
I mount a directory from my NAS here to copy all the files from my computer to the NAS.

I have a cron job that is called at 3:00 AM on the 3rd day of every month.

* 3 3 * * storeBackupMount.pl -f /etc/storebackup.d/storebackupmount.conf

The cron job calls the storeBackupMount file which mounts the NAS drive to /mnt/NAS-Backup and then calls storeBackup.pl which copies the files from my computer to the NAS, which then returns to storeBackupMount which umounts the NAS.

This file resides in /var/spool/cron/tabs and is named as my account.
The directories /etc/cron.d, /etc/cron.daily, /etc/cron.hourly, /etc/cron.monthly and /etc/cron.weekly are empty.

This was all working as it should until I upgraded from 15.3 to 15.4.
Now, at midnight every day, something is starting storeBackup without calling storeBackupMount which, as you can guess, results in an copy of all files on my computer being placed in /mnt/NAS-Backup and runs the root drive out of space.

I have looked at systemd Journal and see 3 lines that say:
Started User Manager for UID 65534
Started Session c1 of User nobody
pam_unix(su:session): opened for user nobody by (uid=0)

These lines are followed by messages that I recognize from storeBackup, so I know it is actually that program that is running.
(I was unable to copy and paste the lines from the display)

So, how can that be?
It must NOT be cron as the program being called is storeBackup.pl and not storeBackupMount.pl

How can cron start a job that is not in a crontab file?

Is there anything besides cron that can start that job?

Is there anyplace where fluff could reside that could cause this?

I have run out of places to look.

Bart

2

Understanding systemd may help a lot for tracking down the culprit: Redirect Notice

3

@montana_suse_user:

I mount a NAS box via NFS automounter maps as follows –

  • Typical map entry – “NFS -rw,hard «Host Name
    ».«Domain Name»:/NFS” - Typical auto.master file entry – “/mnt/«NAS box mount point
    » file:/etc/auto.«autofs map File Name» --timeout=120” - Bash script file line –

if  -d /mnt/«NAS box mount point»/NFS/$effectiveUserID/$systemHostName ]]
then
 .
 .
 .
fi

The secret is, to hit the directory on the NAS box where the access is required exactly and directly –

  • Don’t bother messing about with higher level directories (NFS) exported by the NAS box.
  • The time taken to (NFS) mount the NAS box is about 50 milii-seconds –

 > time if  -d /mnt/xxx/NFS/yyy/zzz ]]; then echo ""; fi


real    0m0,052s
user    0m0,000s
sys     0m0,000s
 > 
dcu@eck001:..Users/dcu> mount
 .
 .
aaa.bbb.ccc:/NFS on /mnt/xxx/NFS type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=«*IPv6 address*»,local_lock=none,addr=«*IPv6 address*»)
 .
 >
4

Mounting would warrant extra fun with IT services of a global player in Erlangen switching from time sharing on mainframes to workstations connected through Ethernet. Sysadmins would develop buggy scripts for mounting and backup as the original poster did. Stale mounts would cause zombies which would eat 99% of available cpu cycles and survived every killing method but rebooting the workstations. Backups to mount directories would fill system disk and more fun was lurking. udev made the problem virtually go away.

On host erlangen udisks would interfere with scanning for SATA disks and disabling them. The following rule hides the HDDs from udisks. Beware, existing rules may supersede the following:

**erlangen:~ #** cat /etc/udev/rules.d/99-udisks2.rules  
# UDISKS_FILESYSTEM_SHARED 
# ==1: mount filesystem to a shared directory (/media/VolumeName) 
# ==0: mount filesystem to a private directory (/run/media/$USER/VolumeName) 
# See udisks(8) 
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{UDISKS_FILESYSTEM_SHARED}="1" 
**SUBSYSTEM=="block", ENV{ID_FS_UUID}=="2260f160-cc05-47cc-9893-cc32c050177d", ENV{UDISKS_IGNORE}="1" 
SUBSYSTEM=="block", ENV{ID_FS_UUID}=="f5177cae-4082-44ed-9471-b99030f06866", ENV{UDISKS_IGNORE}="1" **
**erlangen:~ #**

Scan bus and mount the backup disk:

**erlangen:~ #** cat /usr/local/bin/scan-for-backup-disk 
#!/bin/bash  
#set -x 
scan=/sys/devices/pci0000:00/0000:00:01.2/0000:04:00.1/ata2/host1/scsi_host/host1/scan 
delete=/sys/devices/pci0000:00/0000:00:01.2/0000:04:00.1/ata2/host1/target1:0:0/1:0:0:0/delete 
disk=/dev/disk/by-uuid/2260f160-cc05-47cc-9893-cc32c050177d 
# 
until  -f $delete ] ; do echo "- - -" > $scan ; sleep 1; done 
until  -L $disk ] ; do echo Scanning backup disk ; sleep 1; done 
 -d /HDD/backup ] || mount /HDD || true 
**erlangen:~ #**

Disable the backup disk:

**erlangen:~ #** cat /usr/local/bin/disable-backup-disk  
#!/bin/bash 
delete=/sys/devices/pci0000:00/0000:00:01.2/0000:04:00.1/ata2/host1/target1:0:0/1:0:0:0/delete 
 -d /HDD/backup ] && umount /HDD || true 
 -f $delete ] && echo 1 > $delete || true 
/usr/bin/rm -f /dev/disk/by-uuid/2260f160-cc05-47cc-9893-cc32c050177d 
**erlangen:~ #**

Backup service:

**erlangen:~ #** systemctl cat backup-home.service  
**# /etc/systemd/system/backup-home.service**
[Unit] 
Description=Backup /home 

[Service] 
ExecStartPre=/usr/local/bin/scan-for-backup-disk 
ExecStart=/usr/bin/rsync -a --exclude=.cache --exclude=covid-19-data /home/ /HDD/backup/home/ 
ExecStopPost=/usr/local/bin/disable-backup-disk 
**erlangen:~ #**
5

I don’t want the backup directory mounted at all times, only while doing a backup.
I have found that apparently, the upgrade process enabled the /usr/lib/systemd/system/storeBackup.service. And the default timer file was marked as daily.

Obviously, this is not what I wanted. I did:

systemctl stop storeBackup.service
systemctl disable storeBackup.service
systemctl stop storeBackup.timer
systemctl disable storeBackup.timer

and, actually, moved these two files to a directory where the system can’t find them.

This seems to have fixed the problem.

Looking at the other computers on my network, I see that they are doing the same thing. Except for the server which does not have a graphical desktop. So, it just might be that kde decided to enable these services. I’m not sure.

Didn’t have time to create a cron job to see if the system works as I want now, bit I will, and if it does, I’ll then hide the files on the other machines.

Bart

6

Don’t tinker with /usr/lib/systemd/system: debian - What's the difference between /usr/lib/systemd/system and /etc/systemd/system? - Unix & Linux Stack Exchange

erlangen:~ # find /etc/systemd/ -type f
/etc/systemd/network/20-wired.network
/etc/systemd/network/30-wireless.network
/etc/systemd/system/btrfs-balance.timer.d/schedule.conf
/etc/systemd/system/btrfs-scrub.timer.d/schedule.conf
/etc/systemd/system/FR735.service
/etc/systemd/system/GARMIN.service
/etc/systemd/system/alsa-restore.service.save
/etc/systemd/system/fetchmail.service.save
/etc/systemd/system/fetchmail.timer
/etc/systemd/system/minidlna.service
/etc/systemd/system/sound-extra.service.save
/etc/systemd/system/wpa_supplicant@.service
/etc/systemd/system/test-backup.service
**/etc/systemd/system/hdparm.service**
/etc/systemd/system/backup-home-WD25.service
**/etc/systemd/system/hdparm.timer**
/etc/systemd/system/hd-parm.service
/etc/systemd/system/test-backup-home.service
/etc/systemd/system/smartd.timer
/etc/systemd/system/smartd.service.saved
/etc/systemd/system/backup-home.service
/etc/systemd/system/systemd-suspend.service
/etc/systemd/system/dup.timer
/etc/systemd/system/dup.service
/etc/systemd/system/dupa.service
/etc/systemd/system/fetchmail.service
/etc/systemd/system/HDD-scan.service
/etc/systemd/system/HDD-disable.service
/etc/systemd/system/backup-home.timer
/etc/systemd/system.conf.d/limits.conf
/etc/systemd/journald.conf
/etc/systemd/sleep.conf
/etc/systemd/user.conf
/etc/systemd/networkd.conf
/etc/systemd/resolved.conf
/etc/systemd/system.conf
/etc/systemd/timesyncd.conf
/etc/systemd/logind.conf
erlangen:~ #

hdparm units sit there for years and never get activated by a system upgrade.


erlangen:~ # systemctl status hdparm.timer hdparm.service 
○ hdparm.timer - Start hdparm service
     Loaded: loaded (/etc/systemd/system/hdparm.timer; disabled; vendor preset: disabled)
     Active: inactive (dead)
    Trigger: n/a
   Triggers: ● hdparm.service

○ hdparm.service - hdparm check status
     Loaded: loaded (/etc/systemd/system/hdparm.service; static)
     Active: inactive (dead)
erlangen:~ #
7

Well, storeBackup was sitting on my system since 15.2 and never started itself. My backup system was working just fine. I did an upgrade to 15.4 and, all by itself, on four different computers, this problem arises. I didn’t fuss with the mentioned file itself, I just disabled the storeBackup service and timer. And, just in case, I hid the files so systemctl can’t find them in case a update decides I should run my system as someone else thinks I should, not how I want it.

This might be a hard nosed attitude, but after what the programmers said about kde’s cube, and what was said about keepassxc, I feel justified.

I’m going to create a cron job right now to be sure my system works as I want, and if so, that’ll be it.

Thanks though for your response!

Bart

8

Even if it worked for some time tinkering with /usr/lib/systemd is asking for trouble.

I did an upgrade to 15.4 and, all by itself, on four different computers, this problem arises. I didn’t fuss with the mentioned file itself, I just disabled the storeBackup service and timer. And, just in case, I hid the files so systemctl can’t find them in case a update decides I should run my system as someone else thinks I should, not how I want it.

Beware of openSUSE presets:

**erlangen:~ #** zypper se -is systemd-presets 
Loading repository data... 
Reading installed packages... 

S | Name                              | Type    | Version   | Arch   | Repository 
--+-----------------------------------+---------+-----------+--------+----------------------- 
i | systemd-presets-branding-openSUSE | package | 12.2-20.1 | noarch | Haupt-Repository (OSS) 
i | systemd-presets-common-SUSE       | package | 15-24.1   | noarch | Haupt-Repository (OSS) 
**erlangen:~ #**

Many scripts are run after upgrading packages. However /etc/systemd is left alone. So put your local stuff there.

Thanks though for your response!

You’re welcome!

9

Hi
Cron is actually a dead thing :wink: Next update it might be gone for good…