3

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
  • 1
    I'm curious what happens with crontab -l? – steeldriver Apr 1 '18 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 '18 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 '18 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 '18 at 11:49
  • @steeldriver - please see the updated info in the post :) – n1k31t4 Apr 1 '18 at 12:36
0

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 '18 at 13:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.