I am running DietPi on a RPI in my network with some docker containers on it.
I recently got the idea to switch off containers when not needed, e.g. during the night, since this will allow my hard drive to switch off and saves a bit of energy.
I do not recall how I found out, but for some reason what I did was to just edit the /etc/crontab file that DietPi has with sudo. Worked like a charm, I had my containers stopped and started just as specified.
But then I wanted to make some changes, change some times, add some other stuff. I did it the same way, edit the /etc/crontab file with sudo. Didn’t work, none of my new additions worked.
I searched online and figured out the better way to do this is use the command “crontab -e”, edit stuff there, then also check with “crontab -l” right after. That worked, now my new containers are all behaving as they should.
But how do I now get rid of the stuff I defined in /etc/crontab? I removed it all from that file, saved it, restarted the system, nothing removed these, they are somehow persisting. I know they do because I use a different log file for these and that log file still gets generated now. How can I fix this?
Bonus question about log files, how can I make them more useful in terms of information? Right now they just name the command, not even a timestamp or anything.
Thanks!
Crontabs can live in different places on different systems, but generally when you run
crontab -eyou’re editing the crontab of the current user, which is generally placed in /var/spool/cron/{username}. If you dosudo crontab -ethat edits the crontab/file for root. There can be other files nested in /etc/cron.d, /etc/cron.hourly, /etc/cron.daily et cetera as well.To find out where those old cronjobs are still defined, you can recursive grep the name of that unique log file you mentioned (if the log file is part of the command in the crontab).
grep -r "{unique log file name}" /etcand/var/spoolshould find it. If the log file name isn’t in the command, grep for some other unique string from that cronjob that would stand out amidst everything else in /etc.To add timestamps to log output, you can pipe it through
ts.Solid suggestion, I’ll try that later, thanks! Also thanks for writing out the grep command, I would have asked otherwise.
If you can, just ditch crontabs and use systemd timers. Systemd tiners are available for ages on most distributions and are a way slicker version of cronjobs, with built in logging etc. – you need to create a systemd service in addition though.
If you use a non-systemd OS you can still use something else than cronjobs. Most service managers have a timer option which is more modern.
Thanks, didn’t know. I’ll make a note for next time when I start over with a system, I think for now I stick with crontab for this case.
One thing I read is that systemd will spam logs with timer started/stopped and there is no way to prevent that.
Why would you prevent it? You can just filter the logs.
You can reduce the log level of your .service to a lower one, e.g.
LogLevelMax=warningDefault is usually “info”.
Bonus question about log files, how can I make them more useful in terms of information? Right now they just name the command, not even a timestamp or anything.
Use a wrapper script which echo’s some useful output like “stopping container xy … stopped” and put the output of that in the log. Systemd units do it by default but you can also pipe it to rsyslogd or a similar logging service, or use specialised logging tools and monitoring like victorialogs.
