Debian user cron files

Most cron implementations, including the one used in Debian, are based on the ancient Vixie Cron, named for its author, Paul Vixie. Vixie Cron didn't see an upstream release in two decades. Wikipedia says that in , vixie cron 4. A multitude of enhancements and accompanying software has surfaced, and time-based job scheduling is today one of the places where different Linux distributions do actually still differ from each other. This article tries to summarize the situation and was motivated by a short debian-devel thread about the current state of affairs.

This Wiki Page is rather new written on Feel free to point out errors and fix them. Chapter 9. These crontabs usually get maintained via the crontab 1 tool.

This, for example, is a Debian addition and not supported in plain Vixie cron should you still find one. It is currently unknown whether there are packages that depend on the lexical sort order of cron jobs to be executed. Software currently in Debian Package maintainers of cron-related software, please feel free to add a section about your software. The list given here is most probably incomplete and omission doesn't imply an opinion. It's a heavily patched Vixie Cron 3. For example, an reboot time has been added to allow processes to run after the system was brought up.

If a system is not up and running at the time a cron job is scheduled to run, the job is not executed, which makes this version of cron hard to use on personal machines that get turned off or sent to sleep at night. The rwb account not the root account is getting mail about the job failing, and it's failing because.

Note that su 8 can confuse crontab and that if you are running inside of su 8 you should always use the -u option for safety's sake.

In Debian 10 release, Debian abandoned the old su command from the shadow-utils codebase, and moved into su from the util-linux codebase. This caused a number of subtle changes.

The default set-up of Debian 10 allows multiple people to have root access and still have their own personal preferences take effect while using root privileges if they wish. But as a consequence, using just su or sudo -s will result in an incomplete change of environment variables: for example, after transitioning from rwb to root with a plain su , the USER environment variable will still have a value of rwb. This variable is what some programs and scripts use to identify the user.

Effectively, you still edited your own personal crontab file, not root's. If you want to "fully become root", with a complete re-initialization of environment variables, you'll need to use su - or sudo -i.

I mess about with different distros mostly Debian , and the environment is not always the same. I use a little trick to get cron to tell me what it's environment is:. As you'll likely see, there are substantial diffs between the two environments.

This gets you the root crontab that is substantially different from your user crontab. As before, you can run the printenv in the root crontab to examine the diffs in environments. When you need elevated privileges in a cron job, this is the way to go. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog. Podcast Making Agile work for data science.

Stack Gives Back Featured on Meta. New post summary designs on greatest hits now, everywhere else eventually. Related 5. Hot Network Questions.