Post by @FridaVanMercury@discuss.tchncs.de

@FridaVanMercury@discuss.tchncs.de

2026-11-07 06:04 UTC

Crontab mess on DietPi, how to fix 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!

Replies (3)

@mlfh@lm.mlfh.org 2026-11-07 07:17

Crontabs can live in different places on different systems, but generally when you run crontab -e you’re editing the crontab of the current user, which is generally placed in /var/spool/cron/{username}. If you do sudo crontab -e that 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 thst unique log file you mentioned (if the log file is part of the command in the crontab). grep -r “{unique log file name}” /etc and /var/spool should 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.

Open ##5496642
@helix@feddit.org 2026-11-07 09:31

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.

Open ##5497038
@helix@feddit.org 2026-11-07 09:35

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.

Open ##5497051