Never mind, twas a permissions issue.

If this is a systemd distro, you can just create a timer and service. That way instead of sending a mail message, it's automatically part of the logging for that unit.

If it's a recent version of systemd, you can have a user based systemd that doesn't need escalated privileges. I just finished setting up borg for backup since I'm on Fedora Silverblue now (couldn't use the old way), and I just set up user based systemd units to do the backup.

@Obsolesce said in Converting a cron job to a systemd timer:

First some info as it may have impact on whether or not to do this in the first place:

I have a SaltStack deployment of 600-ish minions. Currently, I have a highstate set to run every 45 minutes via cron:

*/45 * * * * root /usr/bin/salt -b 25\% '*' state.apply

I know one of the benefits of systemd over cron is the logging, and I think this would be great to have better logging of when this runs. More can potentially be done with it automatically, like look for issues and send emails just as one easy example.

But I don't know how to test this... maybe it doesn't produce the kind of log I want, and salt may already do this in it's own log even better. Or maybe this will produce a log that's too big and cause issues later. I can watch it in the beginning either way, so it's fine.

Can that cron job be converted into a reliable systemd timer? If so, how?

600ish minions. Wow. Curious about your setup. (Types of systems, types of states, how to manage and review output of all of that, etc.” Maybe an upcoming post? 🙂

@dustinb3403 said in Need some help with crontab:

Ok and that is what it was.

Simply needed to make a bash script out of it and have it scheduled to run, rather than using the commands directly in cron.

Problem solved.

Solution:

pwd /usr/bin/local touch expiring-alert.sh vi expiring-alert.sh /usr/bin/php /var/www/html/snipeit/artisan snipeit:expiring-alerts sudo vi /etc/crontab 35 * * * 1 <user> /usr/local/bin/expiring-alert.sh

Presumably changing this to be @daily or @weekly would work as well.

MOst of the time that is how I have it setup on my crontab, same for my certbot scripts too.

I also had to fix a permissions issue from a while back, that wasn't affecting anything until I went to get this feature to be functional.

@DustinB3403 said in CentOS rsync between servers using keyfile to pass credentials:

Nevermind, seems to work when I don't bother telling the system to use the authorized key.

That IS kinda the idea. ssh just handles that for you, even when called from another program like rsync.

@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:

@JaredBusch well never considered the workload on servers. I don't know how they manage it! maybe not so many use unattended upgraqdes in debian.

I definitely feel like Ubuntu users don't keep their systems as up to date 😉

@Sparkum said in Crontab troubleshooting:

@scottalanmiller
Using Ubuntu 14.04

Oh okay, probably on the legacy system still then. In that case, what you are looking to do is better done with...

/etc/init.d/servicename status

Thanks!