TOPIC: JOB SCHEDULING
When CRON is stalled by incorrect file and folder permissions
8th October 2021During the past week, I rebooted my system only to find that a number of things no longer worked, and my Pi-hole DNS server was among them. Having exhausted other possibilities by testing out things on another machine, I did a status check when I spotted a line like the following in my system logs and went investigating further:
cron[322]: (root) INSECURE MODE (mode 0600 expected) (crontabs/root)
It turned out to be more significant than I had expected because this was why every CRON job was failing and that included the network set up needed by Pi-hole; a script is executed using the @reboot directive to accomplish this, and I got Pi-hole working again by manually executing it. The evening before, I did introduce some changes to file permissions under /var/www, but I was not expecting it to affect other parts of the /var, though that may have something to do with some forgotten heavy-handedness. The cure was to issue a command like the following for execution in a terminal session:
sudo chmod -R 600 /var/spool/cron/crontabs/
Then, CRON itself needed to start since it had not been running at all and executing this command did the needful without restarting the system:
sudo systemctl start cron
That outcome was proved by executing the following command to issue some terminal output that include the welcome text "active (running)" highlighted in green:
sudo systemctl status cron
There was newly updated output from a frequently executing job that checked on web servers for me, but this was added confirmation. It was a simple solution to a perplexing situation that led up all sorts of blind alleys before I alighted on the right solution to the problem.
Running cron jobs using the www-data system account
22nd December 2018When you set up your own web server or use a private server (virtual or physical), you will find that web servers run using the www-data account. That means that website files need to be accessible to that system account if not owned by it. The latter is mandatory if you want WordPress to be able to update itself with needing FTP details.
It also means that you probably need scheduled jobs to be executed using the privileges possessed by the www-data account. For instance, I use WP-CLI to automate spam removal and updates to plugins, themes and WordPress itself. Spam removal can be done without the www-data account, but the updates need file access and cannot be completed without this. Therefore, I got interested in setting up cron jobs to run under that account and the following command helps to address this:
sudo -u www-data crontab -e
For that to work, your own account needs to be listed in /etc/sudoers or be assigned to the sudo group in /etc/group. If it is either of those, then entering your own password will open the cron file for www-data, and it can be edited as for any other account. Closing and saving the session will update cron with the new job details.
In fact, the same approach can be taken for a variety of commands where files only can be accessed using www-data. This includes copying, pasting and deleting files as well as executing WP-CLI commands. The latter issues a striking message if you run a command using the root account, a pervasive temptation given what it allows. Any alternative to the latter has to be better from a security standpoint.
Controlling clearance of /tmp on Linux systems
19th June 2015While some may view the behaviour in a less favourable, I always have liked the way that Linux can clear its /tmp directory every time the system is restarted. The setting for this is in /etc/default/rcS and the associated line looks something like:
TMPTIME=0
The value of 0 means that the directory is flushed completely every time the system is restarted, but there are other options. A setting of -1 makes the directory behave like any other one on the system, where any file deletions are manual affairs. Using other positive integer values like 7 will specify the number of days that a file can stay in /tmp before it is removed.
What brought me to this topic was the observation that my main Linux Mint system was accumulating files in /tmp and the cause was the commenting out of the TMPTIME=0 line in /etc/default/rcS. This is not the case on Ubuntu, and using that is how I got accustomed to automatic file removal from /tmp in the first place.
All of this discussion so far has pertained to PC's where systems are turned off or restarted regularly. Things are different for servers of course and I have seen tools like tmpreaper and tmpwatch being given a mention. As if to prove that there is more than one way to do anything on Linux, shell scripting and cron remain an ever present fallback.
A peculiarity with PROC EXPORT
10th June 2007I have just encountered an issue with PROC EXPORT that I did not expect to see: it needs to run in a windowing environment. The way that I found this was that I was running a SAS macro as part of a batch job in a headless UNIX session and my program stopped dead with the job needing to be killed; that returned a message containing something about SAS/FSP and SAS/AF which does explain things. Still, this was not something that I would have expected with an export to a CSV file; the behaviour sounds more what you see with the likes of PROC GPLOT or PROC REPORT. As it happened, adding the -noterminal option to the batch command line sorted things out.