crontab -e does not open the crontab for this user
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO9GURib1T8z7lCwjOGLQaGtrueEthgQ8LO42ZX8cOfTqDK4jvDDpKkLFwf2J49kYCMNW7d4ABih_XCb_2UXdq5fPJDkoyg7-8g_YfRUot-XnaXkNYycsNp7lA5_TW9td0FFpLQ2APzKcZ/s1600/1.jpg)
![Creative The name of the picture](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYQ0N5W1qAOxLP7t7iOM6O6AzbZnkXUy16s7P_CWfOb5UbTQY_aDsc727chyphenhyphen5W4IppVNernMMQeaUFTB_rFzAd95_CDt-tnwN-nBx6JyUp2duGjPaL5-VgNO41AVsA_vu30EJcipdDG409/s400/Clash+Royale+CLAN+TAG%2523URR8PPP.png)
up vote
3
down vote
favorite
I had set up a few jobs using crontab
a few months back and they had been working well up until a few days ago, I noticed one had not run. I just tried to check the crontab file using the user that created the jobs, using crontab -e
, and no file opens. Terminal quickly flitts tosome screen and then back to the screen where I had entered the command. It goes and comes back too quickly for me to see what is there.
I have (as sudo) checked under /var/spool/cron/crontab/
and see there is a file for the mentioned user, which contains the basic:
> DO NOT EDIT THIS FILE - edit the master and reinstall.
> (- installed on Wed Mar 21 00:12:22 2018)
> (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
I notice that the isntall date is pretty much exactly where my cron jobs stopped! Maybe the system needed a restart for some reason...
I restarted the machine and again tried: crontab -e
, this time I got the following error coming from Emacs
(the default editor, I believe):
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
.... [truncated]
So I changed the default editor to nano
:
user@user:~$ select-editor
Select an editor. To change later, run 'select-editor'.
1. /bin/ed
2. /bin/nano <---- easiest
3. /usr/bin/code
4. /usr/bin/emacs24
5. /usr/bin/vim.tiny
Choose 1-5 [2]: 2
... and tried again:
user@user:~$ crontab -e
This just gave the same problem as initially described - it shortly seemed to open a file then close it again.
Is there another way to debug and (hopefully) get back the original crontab file? The jobs were quit complex to set up (see note #2 below) :-/
I tried to find running crontab tasks using this answer, so cron is running, but what about my crontab tasks?
user@user:~$ ps -o pid,sess,cmd afx | egrep "( |/)cron( -f)?$"
1077 1077 /usr/sbin/cron -f
Other notes:
- anacron is installed
- the cron jobs themselves are defined in the crontab file, not via external scripts
- one cronjob used a virtual env, which does still exist and works and I can execute the job manually
Updates:
The output from some further checks (mostly requested by @steeldriver)
user@user:~$ ls -l $(which crontab)
-rwxr-sr-x 1 root crontab 36080 Apr 5 2016 /usr/bin/crontab
Is that the setuid
s in there? I compared it to ping
, because I read that should have some kind of elevated permissions:
user@user:~$ ls -l $(which ping)
-rwsr-xr-x 1 root root 44168 Mai 7 2014 /bin/ping
Running crontab
as sudo:
user@user:~$ sudo crontab -e
[sudo] password for user:
no crontab for root - using an empty one
No modification made
Trying the desired command as sudo, using the user's setup:
user@user:~$ sudo -H -u user bash -c 'crontab -e'
No modification made
Checking if permissions for the entire spool are as expected:
user@user:~$ ls -ld /tmp
drwxrwxrwt 16 root root 36864 Apr 1 14:22 /tmp
user@user:~$ sudo namei -l /var/spool/cron/crontabs/$USER
f: /var/spool/cron/crontabs/user
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root spool
drwxr-xr-x root root cron
drwx-wx--T root crontab crontabs
-rw------- user crontab user
command-line cron
 |Â
show 8 more comments
up vote
3
down vote
favorite
I had set up a few jobs using crontab
a few months back and they had been working well up until a few days ago, I noticed one had not run. I just tried to check the crontab file using the user that created the jobs, using crontab -e
, and no file opens. Terminal quickly flitts tosome screen and then back to the screen where I had entered the command. It goes and comes back too quickly for me to see what is there.
I have (as sudo) checked under /var/spool/cron/crontab/
and see there is a file for the mentioned user, which contains the basic:
> DO NOT EDIT THIS FILE - edit the master and reinstall.
> (- installed on Wed Mar 21 00:12:22 2018)
> (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
I notice that the isntall date is pretty much exactly where my cron jobs stopped! Maybe the system needed a restart for some reason...
I restarted the machine and again tried: crontab -e
, this time I got the following error coming from Emacs
(the default editor, I believe):
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
.... [truncated]
So I changed the default editor to nano
:
user@user:~$ select-editor
Select an editor. To change later, run 'select-editor'.
1. /bin/ed
2. /bin/nano <---- easiest
3. /usr/bin/code
4. /usr/bin/emacs24
5. /usr/bin/vim.tiny
Choose 1-5 [2]: 2
... and tried again:
user@user:~$ crontab -e
This just gave the same problem as initially described - it shortly seemed to open a file then close it again.
Is there another way to debug and (hopefully) get back the original crontab file? The jobs were quit complex to set up (see note #2 below) :-/
I tried to find running crontab tasks using this answer, so cron is running, but what about my crontab tasks?
user@user:~$ ps -o pid,sess,cmd afx | egrep "( |/)cron( -f)?$"
1077 1077 /usr/sbin/cron -f
Other notes:
- anacron is installed
- the cron jobs themselves are defined in the crontab file, not via external scripts
- one cronjob used a virtual env, which does still exist and works and I can execute the job manually
Updates:
The output from some further checks (mostly requested by @steeldriver)
user@user:~$ ls -l $(which crontab)
-rwxr-sr-x 1 root crontab 36080 Apr 5 2016 /usr/bin/crontab
Is that the setuid
s in there? I compared it to ping
, because I read that should have some kind of elevated permissions:
user@user:~$ ls -l $(which ping)
-rwsr-xr-x 1 root root 44168 Mai 7 2014 /bin/ping
Running crontab
as sudo:
user@user:~$ sudo crontab -e
[sudo] password for user:
no crontab for root - using an empty one
No modification made
Trying the desired command as sudo, using the user's setup:
user@user:~$ sudo -H -u user bash -c 'crontab -e'
No modification made
Checking if permissions for the entire spool are as expected:
user@user:~$ ls -ld /tmp
drwxrwxrwt 16 root root 36864 Apr 1 14:22 /tmp
user@user:~$ sudo namei -l /var/spool/cron/crontabs/$USER
f: /var/spool/cron/crontabs/user
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root spool
drwxr-xr-x root root cron
drwx-wx--T root crontab crontabs
-rw------- user crontab user
command-line cron
1
I'm curious what happens withcrontab -l
?
â steeldriver
Apr 1 at 10:41
@steeldriver - Nothing comes back at all! (Not a good sign, I know) Assuming the worst - the crontab file was removed somehow - how can we explain thatcrontab -e
doesn't let me at least start a new file?
â n1k31t4
Apr 1 at 10:54
I'd check the permissions of the crontab binary e.g.ls -l $(which crontab)
- does it have its SETUID bit? is the temporary directory writable and sticky (ls -ld /tmp
)? Are the spool permissions correct all the way down (sudo namei -l /var/spool/cron/crontabs/$USER
)?
â steeldriver
Apr 1 at 11:47
also does root's work (sudo crontab -e
). AFAIK the default editor isnano
(or possibly evened
) - I don't think emacs is even installed in the vanilla Ubuntu.
â steeldriver
Apr 1 at 11:49
@steeldriver - please see the updated info in the post :)
â n1k31t4
Apr 1 at 12:36
 |Â
show 8 more comments
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I had set up a few jobs using crontab
a few months back and they had been working well up until a few days ago, I noticed one had not run. I just tried to check the crontab file using the user that created the jobs, using crontab -e
, and no file opens. Terminal quickly flitts tosome screen and then back to the screen where I had entered the command. It goes and comes back too quickly for me to see what is there.
I have (as sudo) checked under /var/spool/cron/crontab/
and see there is a file for the mentioned user, which contains the basic:
> DO NOT EDIT THIS FILE - edit the master and reinstall.
> (- installed on Wed Mar 21 00:12:22 2018)
> (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
I notice that the isntall date is pretty much exactly where my cron jobs stopped! Maybe the system needed a restart for some reason...
I restarted the machine and again tried: crontab -e
, this time I got the following error coming from Emacs
(the default editor, I believe):
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
.... [truncated]
So I changed the default editor to nano
:
user@user:~$ select-editor
Select an editor. To change later, run 'select-editor'.
1. /bin/ed
2. /bin/nano <---- easiest
3. /usr/bin/code
4. /usr/bin/emacs24
5. /usr/bin/vim.tiny
Choose 1-5 [2]: 2
... and tried again:
user@user:~$ crontab -e
This just gave the same problem as initially described - it shortly seemed to open a file then close it again.
Is there another way to debug and (hopefully) get back the original crontab file? The jobs were quit complex to set up (see note #2 below) :-/
I tried to find running crontab tasks using this answer, so cron is running, but what about my crontab tasks?
user@user:~$ ps -o pid,sess,cmd afx | egrep "( |/)cron( -f)?$"
1077 1077 /usr/sbin/cron -f
Other notes:
- anacron is installed
- the cron jobs themselves are defined in the crontab file, not via external scripts
- one cronjob used a virtual env, which does still exist and works and I can execute the job manually
Updates:
The output from some further checks (mostly requested by @steeldriver)
user@user:~$ ls -l $(which crontab)
-rwxr-sr-x 1 root crontab 36080 Apr 5 2016 /usr/bin/crontab
Is that the setuid
s in there? I compared it to ping
, because I read that should have some kind of elevated permissions:
user@user:~$ ls -l $(which ping)
-rwsr-xr-x 1 root root 44168 Mai 7 2014 /bin/ping
Running crontab
as sudo:
user@user:~$ sudo crontab -e
[sudo] password for user:
no crontab for root - using an empty one
No modification made
Trying the desired command as sudo, using the user's setup:
user@user:~$ sudo -H -u user bash -c 'crontab -e'
No modification made
Checking if permissions for the entire spool are as expected:
user@user:~$ ls -ld /tmp
drwxrwxrwt 16 root root 36864 Apr 1 14:22 /tmp
user@user:~$ sudo namei -l /var/spool/cron/crontabs/$USER
f: /var/spool/cron/crontabs/user
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root spool
drwxr-xr-x root root cron
drwx-wx--T root crontab crontabs
-rw------- user crontab user
command-line cron
I had set up a few jobs using crontab
a few months back and they had been working well up until a few days ago, I noticed one had not run. I just tried to check the crontab file using the user that created the jobs, using crontab -e
, and no file opens. Terminal quickly flitts tosome screen and then back to the screen where I had entered the command. It goes and comes back too quickly for me to see what is there.
I have (as sudo) checked under /var/spool/cron/crontab/
and see there is a file for the mentioned user, which contains the basic:
> DO NOT EDIT THIS FILE - edit the master and reinstall.
> (- installed on Wed Mar 21 00:12:22 2018)
> (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
I notice that the isntall date is pretty much exactly where my cron jobs stopped! Maybe the system needed a restart for some reason...
I restarted the machine and again tried: crontab -e
, this time I got the following error coming from Emacs
(the default editor, I believe):
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
Warning: due to a long standing Gtk+ bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715
.... [truncated]
So I changed the default editor to nano
:
user@user:~$ select-editor
Select an editor. To change later, run 'select-editor'.
1. /bin/ed
2. /bin/nano <---- easiest
3. /usr/bin/code
4. /usr/bin/emacs24
5. /usr/bin/vim.tiny
Choose 1-5 [2]: 2
... and tried again:
user@user:~$ crontab -e
This just gave the same problem as initially described - it shortly seemed to open a file then close it again.
Is there another way to debug and (hopefully) get back the original crontab file? The jobs were quit complex to set up (see note #2 below) :-/
I tried to find running crontab tasks using this answer, so cron is running, but what about my crontab tasks?
user@user:~$ ps -o pid,sess,cmd afx | egrep "( |/)cron( -f)?$"
1077 1077 /usr/sbin/cron -f
Other notes:
- anacron is installed
- the cron jobs themselves are defined in the crontab file, not via external scripts
- one cronjob used a virtual env, which does still exist and works and I can execute the job manually
Updates:
The output from some further checks (mostly requested by @steeldriver)
user@user:~$ ls -l $(which crontab)
-rwxr-sr-x 1 root crontab 36080 Apr 5 2016 /usr/bin/crontab
Is that the setuid
s in there? I compared it to ping
, because I read that should have some kind of elevated permissions:
user@user:~$ ls -l $(which ping)
-rwsr-xr-x 1 root root 44168 Mai 7 2014 /bin/ping
Running crontab
as sudo:
user@user:~$ sudo crontab -e
[sudo] password for user:
no crontab for root - using an empty one
No modification made
Trying the desired command as sudo, using the user's setup:
user@user:~$ sudo -H -u user bash -c 'crontab -e'
No modification made
Checking if permissions for the entire spool are as expected:
user@user:~$ ls -ld /tmp
drwxrwxrwt 16 root root 36864 Apr 1 14:22 /tmp
user@user:~$ sudo namei -l /var/spool/cron/crontabs/$USER
f: /var/spool/cron/crontabs/user
drwxr-xr-x root root /
drwxr-xr-x root root var
drwxr-xr-x root root spool
drwxr-xr-x root root cron
drwx-wx--T root crontab crontabs
-rw------- user crontab user
command-line cron
command-line cron
edited Apr 1 at 12:35
asked Apr 1 at 10:37
![](https://i.stack.imgur.com/uIBJ7.gif?s=32&g=1)
![](https://i.stack.imgur.com/uIBJ7.gif?s=32&g=1)
n1k31t4
1939
1939
1
I'm curious what happens withcrontab -l
?
â steeldriver
Apr 1 at 10:41
@steeldriver - Nothing comes back at all! (Not a good sign, I know) Assuming the worst - the crontab file was removed somehow - how can we explain thatcrontab -e
doesn't let me at least start a new file?
â n1k31t4
Apr 1 at 10:54
I'd check the permissions of the crontab binary e.g.ls -l $(which crontab)
- does it have its SETUID bit? is the temporary directory writable and sticky (ls -ld /tmp
)? Are the spool permissions correct all the way down (sudo namei -l /var/spool/cron/crontabs/$USER
)?
â steeldriver
Apr 1 at 11:47
also does root's work (sudo crontab -e
). AFAIK the default editor isnano
(or possibly evened
) - I don't think emacs is even installed in the vanilla Ubuntu.
â steeldriver
Apr 1 at 11:49
@steeldriver - please see the updated info in the post :)
â n1k31t4
Apr 1 at 12:36
 |Â
show 8 more comments
1
I'm curious what happens withcrontab -l
?
â steeldriver
Apr 1 at 10:41
@steeldriver - Nothing comes back at all! (Not a good sign, I know) Assuming the worst - the crontab file was removed somehow - how can we explain thatcrontab -e
doesn't let me at least start a new file?
â n1k31t4
Apr 1 at 10:54
I'd check the permissions of the crontab binary e.g.ls -l $(which crontab)
- does it have its SETUID bit? is the temporary directory writable and sticky (ls -ld /tmp
)? Are the spool permissions correct all the way down (sudo namei -l /var/spool/cron/crontabs/$USER
)?
â steeldriver
Apr 1 at 11:47
also does root's work (sudo crontab -e
). AFAIK the default editor isnano
(or possibly evened
) - I don't think emacs is even installed in the vanilla Ubuntu.
â steeldriver
Apr 1 at 11:49
@steeldriver - please see the updated info in the post :)
â n1k31t4
Apr 1 at 12:36
1
1
I'm curious what happens with
crontab -l
?â steeldriver
Apr 1 at 10:41
I'm curious what happens with
crontab -l
?â steeldriver
Apr 1 at 10:41
@steeldriver - Nothing comes back at all! (Not a good sign, I know) Assuming the worst - the crontab file was removed somehow - how can we explain that
crontab -e
doesn't let me at least start a new file?â n1k31t4
Apr 1 at 10:54
@steeldriver - Nothing comes back at all! (Not a good sign, I know) Assuming the worst - the crontab file was removed somehow - how can we explain that
crontab -e
doesn't let me at least start a new file?â n1k31t4
Apr 1 at 10:54
I'd check the permissions of the crontab binary e.g.
ls -l $(which crontab)
- does it have its SETUID bit? is the temporary directory writable and sticky (ls -ld /tmp
)? Are the spool permissions correct all the way down (sudo namei -l /var/spool/cron/crontabs/$USER
)?â steeldriver
Apr 1 at 11:47
I'd check the permissions of the crontab binary e.g.
ls -l $(which crontab)
- does it have its SETUID bit? is the temporary directory writable and sticky (ls -ld /tmp
)? Are the spool permissions correct all the way down (sudo namei -l /var/spool/cron/crontabs/$USER
)?â steeldriver
Apr 1 at 11:47
also does root's work (
sudo crontab -e
). AFAIK the default editor isnano
(or possibly even ed
) - I don't think emacs is even installed in the vanilla Ubuntu.â steeldriver
Apr 1 at 11:49
also does root's work (
sudo crontab -e
). AFAIK the default editor isnano
(or possibly even ed
) - I don't think emacs is even installed in the vanilla Ubuntu.â steeldriver
Apr 1 at 11:49
@steeldriver - please see the updated info in the post :)
â n1k31t4
Apr 1 at 12:36
@steeldriver - please see the updated info in the post :)
â n1k31t4
Apr 1 at 12:36
 |Â
show 8 more comments
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
Just to post the outcome and perhaps help someone who sees the same thing - this is a summary of the comments below my original question
Using crontab -e
was the start of the problem - it didn't do anything.
It turns out the Emacs setup was the cause (but I assume any other editor could somehow cause this problem).
Following @steeldriver 's advice of trying EDITOR=/bin/nano crontab -e
(trying to force crontab to use nano did not help.
I recorded a screen-cast and stopped on the frame where a file quickly opens - it was Emacs' splash screen.
There were settings in ~/.profile
, which caused the Emacs daemon to hijack calls to an editor. After removing those setting and restarting, crontab -e
as the user worked.
The settings seemed to be an incorrectly copy-pasted version of this (found on the Emacs wiki):
export ALTERNATE_EDITOR=""
export EDITOR="emacsclient -t" # $EDITOR should open in terminal
export VISUAL="emacsclient -c -a emacs" # $VISUAL opens in GUI with non-daemon as alternate
[I don't remember where the actual mistake was]
The original crontab file was lost. I still don't understand how that happened
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
Just to post the outcome and perhaps help someone who sees the same thing - this is a summary of the comments below my original question
Using crontab -e
was the start of the problem - it didn't do anything.
It turns out the Emacs setup was the cause (but I assume any other editor could somehow cause this problem).
Following @steeldriver 's advice of trying EDITOR=/bin/nano crontab -e
(trying to force crontab to use nano did not help.
I recorded a screen-cast and stopped on the frame where a file quickly opens - it was Emacs' splash screen.
There were settings in ~/.profile
, which caused the Emacs daemon to hijack calls to an editor. After removing those setting and restarting, crontab -e
as the user worked.
The settings seemed to be an incorrectly copy-pasted version of this (found on the Emacs wiki):
export ALTERNATE_EDITOR=""
export EDITOR="emacsclient -t" # $EDITOR should open in terminal
export VISUAL="emacsclient -c -a emacs" # $VISUAL opens in GUI with non-daemon as alternate
[I don't remember where the actual mistake was]
The original crontab file was lost. I still don't understand how that happened
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
add a comment |Â
up vote
0
down vote
accepted
Just to post the outcome and perhaps help someone who sees the same thing - this is a summary of the comments below my original question
Using crontab -e
was the start of the problem - it didn't do anything.
It turns out the Emacs setup was the cause (but I assume any other editor could somehow cause this problem).
Following @steeldriver 's advice of trying EDITOR=/bin/nano crontab -e
(trying to force crontab to use nano did not help.
I recorded a screen-cast and stopped on the frame where a file quickly opens - it was Emacs' splash screen.
There were settings in ~/.profile
, which caused the Emacs daemon to hijack calls to an editor. After removing those setting and restarting, crontab -e
as the user worked.
The settings seemed to be an incorrectly copy-pasted version of this (found on the Emacs wiki):
export ALTERNATE_EDITOR=""
export EDITOR="emacsclient -t" # $EDITOR should open in terminal
export VISUAL="emacsclient -c -a emacs" # $VISUAL opens in GUI with non-daemon as alternate
[I don't remember where the actual mistake was]
The original crontab file was lost. I still don't understand how that happened
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
add a comment |Â
up vote
0
down vote
accepted
up vote
0
down vote
accepted
Just to post the outcome and perhaps help someone who sees the same thing - this is a summary of the comments below my original question
Using crontab -e
was the start of the problem - it didn't do anything.
It turns out the Emacs setup was the cause (but I assume any other editor could somehow cause this problem).
Following @steeldriver 's advice of trying EDITOR=/bin/nano crontab -e
(trying to force crontab to use nano did not help.
I recorded a screen-cast and stopped on the frame where a file quickly opens - it was Emacs' splash screen.
There were settings in ~/.profile
, which caused the Emacs daemon to hijack calls to an editor. After removing those setting and restarting, crontab -e
as the user worked.
The settings seemed to be an incorrectly copy-pasted version of this (found on the Emacs wiki):
export ALTERNATE_EDITOR=""
export EDITOR="emacsclient -t" # $EDITOR should open in terminal
export VISUAL="emacsclient -c -a emacs" # $VISUAL opens in GUI with non-daemon as alternate
[I don't remember where the actual mistake was]
The original crontab file was lost. I still don't understand how that happened
Just to post the outcome and perhaps help someone who sees the same thing - this is a summary of the comments below my original question
Using crontab -e
was the start of the problem - it didn't do anything.
It turns out the Emacs setup was the cause (but I assume any other editor could somehow cause this problem).
Following @steeldriver 's advice of trying EDITOR=/bin/nano crontab -e
(trying to force crontab to use nano did not help.
I recorded a screen-cast and stopped on the frame where a file quickly opens - it was Emacs' splash screen.
There were settings in ~/.profile
, which caused the Emacs daemon to hijack calls to an editor. After removing those setting and restarting, crontab -e
as the user worked.
The settings seemed to be an incorrectly copy-pasted version of this (found on the Emacs wiki):
export ALTERNATE_EDITOR=""
export EDITOR="emacsclient -t" # $EDITOR should open in terminal
export VISUAL="emacsclient -c -a emacs" # $VISUAL opens in GUI with non-daemon as alternate
[I don't remember where the actual mistake was]
The original crontab file was lost. I still don't understand how that happened
answered Apr 4 at 13:12
![](https://i.stack.imgur.com/uIBJ7.gif?s=32&g=1)
![](https://i.stack.imgur.com/uIBJ7.gif?s=32&g=1)
n1k31t4
1939
1939
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
add a comment |Â
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
If somebody has a more general solution to finding out the root cause of something like this, I will accept that answer!
â n1k31t4
Apr 4 at 13:13
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1021021%2fcrontab-e-does-not-open-the-crontab-for-this-user%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
I'm curious what happens with
crontab -l
?â steeldriver
Apr 1 at 10:41
@steeldriver - Nothing comes back at all! (Not a good sign, I know) Assuming the worst - the crontab file was removed somehow - how can we explain that
crontab -e
doesn't let me at least start a new file?â n1k31t4
Apr 1 at 10:54
I'd check the permissions of the crontab binary e.g.
ls -l $(which crontab)
- does it have its SETUID bit? is the temporary directory writable and sticky (ls -ld /tmp
)? Are the spool permissions correct all the way down (sudo namei -l /var/spool/cron/crontabs/$USER
)?â steeldriver
Apr 1 at 11:47
also does root's work (
sudo crontab -e
). AFAIK the default editor isnano
(or possibly evened
) - I don't think emacs is even installed in the vanilla Ubuntu.â steeldriver
Apr 1 at 11:49
@steeldriver - please see the updated info in the post :)
â n1k31t4
Apr 1 at 12:36