crontab -e does not open the crontab for this user

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

Answer 1

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