crontab -e does not open the crontab for this user

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








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









share|improve this question



















  • 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 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














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









share|improve this question



















  • 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 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












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









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 1 at 12:35

























asked Apr 1 at 10:37









n1k31t4

1939




1939







  • 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 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












  • 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 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







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










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






share|improve this answer




















  • 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










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "89"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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






























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






share|improve this answer




















  • 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














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






share|improve this answer




















  • 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












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






share|improve this answer












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







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 4 at 13:12









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
















  • 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

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Popular posts from this blog

pylint3 and pip3 broken

Missing snmpget and snmpwalk

How to enroll fingerprints to Ubuntu 17.10 with VFS491