re-create default crontab [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
3
down vote

favorite













This question already has an answer here:



  • Resetting crontab file to default

    1 answer



In my attempt to make a new crontab file work on 16.04, I made the following mistake as root:



sudo su root
crontab /etc/cron.d/myjob


I realized too late that I must've changed some default crontab behaviour, ie regarding crontab -e. I tried to roll back like this:



# still as root:
crontab /etc/crontab


Is that the correct default setting?
If not, then what is?



PS: The related issue does not answer my question. The answer there only states how to remove a crontab, not how to re-generate the default Ubuntu installation settings which is what I need to know.




cron




share|improve this question














marked as duplicate by karel, Fabby, Eric Carvalho, MadMike, vidarlo May 5 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • Thanks. Your linked issue indicates that the original root crontab was empty. Mine wasn't. I didn't add anything to it myself; I don't know what was in there; I just caught a glimpse of it with crontab -e before I messed up. It was a 3 weeks old 16.04 Unity installation. It must've been the one that ships with the installation; is that /etc/crontab?
    – Jonas Ellehauge
    May 4 at 6:29











  • Here is the contents of /etc/crontab: gist.github.com/ellvtr/c9f804e277d8bd3683766115c68a7877
    – Jonas Ellehauge
    May 4 at 6:47














up vote
3
down vote

favorite













This question already has an answer here:



  • Resetting crontab file to default

    1 answer



In my attempt to make a new crontab file work on 16.04, I made the following mistake as root:



sudo su root
crontab /etc/cron.d/myjob


I realized too late that I must've changed some default crontab behaviour, ie regarding crontab -e. I tried to roll back like this:



# still as root:
crontab /etc/crontab


Is that the correct default setting?
If not, then what is?



PS: The related issue does not answer my question. The answer there only states how to remove a crontab, not how to re-generate the default Ubuntu installation settings which is what I need to know.




cron




share|improve this question














marked as duplicate by karel, Fabby, Eric Carvalho, MadMike, vidarlo May 5 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.














  • Thanks. Your linked issue indicates that the original root crontab was empty. Mine wasn't. I didn't add anything to it myself; I don't know what was in there; I just caught a glimpse of it with crontab -e before I messed up. It was a 3 weeks old 16.04 Unity installation. It must've been the one that ships with the installation; is that /etc/crontab?
    – Jonas Ellehauge
    May 4 at 6:29











  • Here is the contents of /etc/crontab: gist.github.com/ellvtr/c9f804e277d8bd3683766115c68a7877
    – Jonas Ellehauge
    May 4 at 6:47












up vote
3
down vote

favorite









up vote
3
down vote

favorite












This question already has an answer here:



  • Resetting crontab file to default

    1 answer



In my attempt to make a new crontab file work on 16.04, I made the following mistake as root:



sudo su root
crontab /etc/cron.d/myjob


I realized too late that I must've changed some default crontab behaviour, ie regarding crontab -e. I tried to roll back like this:



# still as root:
crontab /etc/crontab


Is that the correct default setting?
If not, then what is?



PS: The related issue does not answer my question. The answer there only states how to remove a crontab, not how to re-generate the default Ubuntu installation settings which is what I need to know.




cron




share|improve this question















This question already has an answer here:



  • Resetting crontab file to default

    1 answer



In my attempt to make a new crontab file work on 16.04, I made the following mistake as root:



sudo su root
crontab /etc/cron.d/myjob


I realized too late that I must've changed some default crontab behaviour, ie regarding crontab -e. I tried to roll back like this:



# still as root:
crontab /etc/crontab


Is that the correct default setting?
If not, then what is?



PS: The related issue does not answer my question. The answer there only states how to remove a crontab, not how to re-generate the default Ubuntu installation settings which is what I need to know.





This question already has an answer here:



  • Resetting crontab file to default

    1 answer





cron





share|improve this question













share|improve this question




share|improve this question








edited May 16 at 6:00

























asked May 3 at 13:15









Jonas Ellehauge

163




163




marked as duplicate by karel, Fabby, Eric Carvalho, MadMike, vidarlo May 5 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






marked as duplicate by karel, Fabby, Eric Carvalho, MadMike, vidarlo May 5 at 21:10


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.













  • Thanks. Your linked issue indicates that the original root crontab was empty. Mine wasn't. I didn't add anything to it myself; I don't know what was in there; I just caught a glimpse of it with crontab -e before I messed up. It was a 3 weeks old 16.04 Unity installation. It must've been the one that ships with the installation; is that /etc/crontab?
    – Jonas Ellehauge
    May 4 at 6:29











  • Here is the contents of /etc/crontab: gist.github.com/ellvtr/c9f804e277d8bd3683766115c68a7877
    – Jonas Ellehauge
    May 4 at 6:47
















  • Thanks. Your linked issue indicates that the original root crontab was empty. Mine wasn't. I didn't add anything to it myself; I don't know what was in there; I just caught a glimpse of it with crontab -e before I messed up. It was a 3 weeks old 16.04 Unity installation. It must've been the one that ships with the installation; is that /etc/crontab?
    – Jonas Ellehauge
    May 4 at 6:29











  • Here is the contents of /etc/crontab: gist.github.com/ellvtr/c9f804e277d8bd3683766115c68a7877
    – Jonas Ellehauge
    May 4 at 6:47















Thanks. Your linked issue indicates that the original root crontab was empty. Mine wasn't. I didn't add anything to it myself; I don't know what was in there; I just caught a glimpse of it with crontab -e before I messed up. It was a 3 weeks old 16.04 Unity installation. It must've been the one that ships with the installation; is that /etc/crontab?
– Jonas Ellehauge
May 4 at 6:29





Thanks. Your linked issue indicates that the original root crontab was empty. Mine wasn't. I didn't add anything to it myself; I don't know what was in there; I just caught a glimpse of it with crontab -e before I messed up. It was a 3 weeks old 16.04 Unity installation. It must've been the one that ships with the installation; is that /etc/crontab?
– Jonas Ellehauge
May 4 at 6:29













Here is the contents of /etc/crontab: gist.github.com/ellvtr/c9f804e277d8bd3683766115c68a7877
– Jonas Ellehauge
May 4 at 6:47




Here is the contents of /etc/crontab: gist.github.com/ellvtr/c9f804e277d8bd3683766115c68a7877
– Jonas Ellehauge
May 4 at 6:47










1 Answer
1






active

oldest

votes

















up vote
1
down vote













Cron utilizes two, quite independent sets of crontab files.



  1. One of them is public (system-wide), located in /etc. It includes /etc/crontab and the files in /etc/cron.d.

    The file you linked looks much like the default /etc/crontab. If you have got this contents in your /etc/crontab file, keep it.



  2. The other includes a private file for each user. Their actual location is /var/spool/cron/crontabs but this folder is not accessible by normal means. These crontab files shall be accessed and modified using the crontab command.

    A user’s crontab (including root, accessed using sudo crontab <option>) does not exist by default. When you issue crontab -e and have no crontab file for given user, the command brings a template with no scheduled commands, just descriptive comments. The file is saved only if you modify the template.

    To reset this one to the default state (i.e. remove it), use the command:



    crontab -r






share|improve this answer


















  • 1




    The user crontab is functionally empty but contains informative comments at the start, iirc.
    – muru
    May 4 at 7:28











  • @muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
    – Melebius
    May 4 at 7:29











  • sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
    – Jonas Ellehauge
    May 16 at 6:03







  • 1




    @JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
    – muru
    May 16 at 6:15











  • Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
    – Jonas Ellehauge
    May 17 at 6:00

















1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













Cron utilizes two, quite independent sets of crontab files.



  1. One of them is public (system-wide), located in /etc. It includes /etc/crontab and the files in /etc/cron.d.

    The file you linked looks much like the default /etc/crontab. If you have got this contents in your /etc/crontab file, keep it.



  2. The other includes a private file for each user. Their actual location is /var/spool/cron/crontabs but this folder is not accessible by normal means. These crontab files shall be accessed and modified using the crontab command.

    A user’s crontab (including root, accessed using sudo crontab <option>) does not exist by default. When you issue crontab -e and have no crontab file for given user, the command brings a template with no scheduled commands, just descriptive comments. The file is saved only if you modify the template.

    To reset this one to the default state (i.e. remove it), use the command:



    crontab -r






share|improve this answer


















  • 1




    The user crontab is functionally empty but contains informative comments at the start, iirc.
    – muru
    May 4 at 7:28











  • @muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
    – Melebius
    May 4 at 7:29











  • sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
    – Jonas Ellehauge
    May 16 at 6:03







  • 1




    @JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
    – muru
    May 16 at 6:15











  • Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
    – Jonas Ellehauge
    May 17 at 6:00














up vote
1
down vote













Cron utilizes two, quite independent sets of crontab files.



  1. One of them is public (system-wide), located in /etc. It includes /etc/crontab and the files in /etc/cron.d.

    The file you linked looks much like the default /etc/crontab. If you have got this contents in your /etc/crontab file, keep it.



  2. The other includes a private file for each user. Their actual location is /var/spool/cron/crontabs but this folder is not accessible by normal means. These crontab files shall be accessed and modified using the crontab command.

    A user’s crontab (including root, accessed using sudo crontab <option>) does not exist by default. When you issue crontab -e and have no crontab file for given user, the command brings a template with no scheduled commands, just descriptive comments. The file is saved only if you modify the template.

    To reset this one to the default state (i.e. remove it), use the command:



    crontab -r






share|improve this answer


















  • 1




    The user crontab is functionally empty but contains informative comments at the start, iirc.
    – muru
    May 4 at 7:28











  • @muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
    – Melebius
    May 4 at 7:29











  • sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
    – Jonas Ellehauge
    May 16 at 6:03







  • 1




    @JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
    – muru
    May 16 at 6:15











  • Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
    – Jonas Ellehauge
    May 17 at 6:00












up vote
1
down vote










up vote
1
down vote









Cron utilizes two, quite independent sets of crontab files.



  1. One of them is public (system-wide), located in /etc. It includes /etc/crontab and the files in /etc/cron.d.

    The file you linked looks much like the default /etc/crontab. If you have got this contents in your /etc/crontab file, keep it.



  2. The other includes a private file for each user. Their actual location is /var/spool/cron/crontabs but this folder is not accessible by normal means. These crontab files shall be accessed and modified using the crontab command.

    A user’s crontab (including root, accessed using sudo crontab <option>) does not exist by default. When you issue crontab -e and have no crontab file for given user, the command brings a template with no scheduled commands, just descriptive comments. The file is saved only if you modify the template.

    To reset this one to the default state (i.e. remove it), use the command:



    crontab -r






share|improve this answer














Cron utilizes two, quite independent sets of crontab files.



  1. One of them is public (system-wide), located in /etc. It includes /etc/crontab and the files in /etc/cron.d.

    The file you linked looks much like the default /etc/crontab. If you have got this contents in your /etc/crontab file, keep it.



  2. The other includes a private file for each user. Their actual location is /var/spool/cron/crontabs but this folder is not accessible by normal means. These crontab files shall be accessed and modified using the crontab command.

    A user’s crontab (including root, accessed using sudo crontab <option>) does not exist by default. When you issue crontab -e and have no crontab file for given user, the command brings a template with no scheduled commands, just descriptive comments. The file is saved only if you modify the template.

    To reset this one to the default state (i.e. remove it), use the command:



    crontab -r







share|improve this answer














share|improve this answer



share|improve this answer








edited Jun 4 at 13:28

























answered May 4 at 7:25









Melebius

3,66841636




3,66841636







  • 1




    The user crontab is functionally empty but contains informative comments at the start, iirc.
    – muru
    May 4 at 7:28











  • @muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
    – Melebius
    May 4 at 7:29











  • sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
    – Jonas Ellehauge
    May 16 at 6:03







  • 1




    @JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
    – muru
    May 16 at 6:15











  • Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
    – Jonas Ellehauge
    May 17 at 6:00












  • 1




    The user crontab is functionally empty but contains informative comments at the start, iirc.
    – muru
    May 4 at 7:28











  • @muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
    – Melebius
    May 4 at 7:29











  • sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
    – Jonas Ellehauge
    May 16 at 6:03







  • 1




    @JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
    – muru
    May 16 at 6:15











  • Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
    – Jonas Ellehauge
    May 17 at 6:00







1




1




The user crontab is functionally empty but contains informative comments at the start, iirc.
– muru
May 4 at 7:28





The user crontab is functionally empty but contains informative comments at the start, iirc.
– muru
May 4 at 7:28













@muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
– Melebius
May 4 at 7:29





@muru You are almost right. If you open the empty crontab using crontab command, you get some placeholder comments. However, they aren’t stored in the /var/spool/cron/crontabs until you save your own crontab.
– Melebius
May 4 at 7:29













sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
– Jonas Ellehauge
May 16 at 6:03





sudo contab -e was not empty before I messed it up. It had actual jobs in there, not just the standard comments. If it was empty by the Ubuntu installation - I only got a short glimpse of it. I assume some applications have added root cronjobs after the installation then.
– Jonas Ellehauge
May 16 at 6:03





1




1




@JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
– muru
May 16 at 6:15





@JonasEllehauge the root user's crontab is empty by default. Any packages that need to run cronjobs use the /etc/cron.* directories. No package edits the root user's crontab.
– muru
May 16 at 6:15













Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
– Jonas Ellehauge
May 17 at 6:00




Thanks, good to know. There were some entries in mine and I didn't add them manually. Here's what's in there now 17 * * * * root cd / && run-parts --report /etc/cron.hourly /n 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) [+more anacron entries]. Looks like anaconda added some. The first one looks like a system entry to me.
– Jonas Ellehauge
May 17 at 6:00


-

Popular posts from this blog

pylint3 and pip3 broken

Image
Clash Royale CLAN TAG #URR8PPP up vote 0 down vote favorite I have tried sudo apt remove --purge on various packages. I get the same when I reinstall. I have also tried reinstall using aptitude. This does not work. My current workaround is to run pylint3 as root, which works, but is bad practice. pip3 $ pip3 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pip/_vendor/__init__.py", line 33, in vendored __import__(vendored_name, globals(), locals(), level=0) ImportError: No module named 'pip._vendor.pkg_resources' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/pip3", line 9, in <module> from pip import main File "/usr/lib/python3/dist-packages/pip/__init__.py", line 13, in <module> from pip.exceptions import InstallationError, CommandError, PipError File "/usr/lib/python3/dist-packages/pip/exceptions.py", line 6, ...
Read more

Missing snmpget and snmpwalk

Image
Clash Royale CLAN TAG #URR8PPP up vote 0 down vote favorite I have installed Zabbix appliance, directly preinstalled and found that there is missing snmpwalk and snmpget commands. I tried to install it with: apt-get install net-snmp-utils but I have error message: Unable to locate package. I have also check what from SNMP is preinstalled and there is: libsnmp-base libsnmp30:amd64 snmp-mibs-downloader snmpd snmptrapd snmptrapfmt How can I install snmpget and snmpwalk ? snmp zabbix share | improve this question edited Jan 29 at 10:10 Yaron 8,552 7 18 38 asked Jan 29 at 9:51 Alfista 1 apt install snmp perhaps ? If named differently - apt cache snmp – fugitive Jan 29 at 10:00 add a comment  |  up vote 0 down vote favorite I have installed Zabbix appliance, directly preinstalled and found that there is missing snmpwalk and snmpget commands. I tried...
Read more

How to enroll fingerprints to Ubuntu 17.10 with VFS491

Image
Clash Royale CLAN TAG #URR8PPP up vote 1 down vote favorite I decided to switch from Windows to Ubuntu 17.10, I meet it like 8 years ago and I didn't decided to switch until now (haha). Well, my actual device is an HP Probook 4540s with a Validity fingerprint sensor (VFS491). The fingerprint sensor worked fine on Windows but I can't get it to work in Ubuntu. The device is recognized as 138a:003d but is not detected as a fingerprint scanner by some apps like Fingerprint GUI. I want to use the fingerprint scanner to log in into my user account in Ubuntu but it doesn't supports fingerprints without special software and the drivers of the fingerprint scanner are available for Windows but not for any Linux distribution. I found something on GitHub (https://github.com/eekpie/libfprint) about the integration of the VFS491 in libfprint and I think it can help but I don't know what to do with it, so that's why I need the help of the community to do it since I am...
Read more