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

Which professions warranted travel in Medieval times?

How do so many people here on Academia.SE, and in general, afford lavish higher education programs?

Trouble downloading packages list due to a “Hash sum mismatch” error