2

I reverted from Linuxmint 18 Cinnamon 64bit to Linuxmint 17.3 Cinnamon 64bit and can no longer create a cron job. I have separate root (/) and home (/home/my-user-name) partitions and left the home partition untouched when I did the 17.3 installation.

I was having all sorts of difficulties creating a cron job, so I installed gnome-scheduler and tried to create a cron job that way. I got a warning dialog box titled

"Warning: Working directory of executed tasks"

and the message content is

"Note about working directory of executed tasks: Recurrent tasks will be run from the home directory."

I clicked OK and the job shows up in the terminal as follows:

$ crontab -l
* * * * * env DISPLAY=:0 /home/my-user-name/wallpaper_changer.sh >/dev/null 2>&1 # JOB_ID_4

My wallpaper does not change every minute as it should. The script runs just fine from the command line and produces no output. Permissions are 744 octal for the script. This all worked fine under Mint 18, but I had the script run just once a day. I set it to run every minute only for testing purposes.

If I try the normal cron job editing method, I get

$ crontab -e
Temporary crontab no longer owned by you.
Error while editing crontab

Then I get an empty nano buffer rather than the normal crontab template full of commented lines. When I try to write my nano buffer to file /tmp/crontab.lmuwIe/crontab I get this error message:

[ Error writing /tmp/lmuwIe/crontab: Permission denied ]

Finally,

$ ls -l /usr/bin/crontab
-rwsr-xr-x 1 root crontab 35984 Feb  9  2013 /usr/bin/crontab

Will I ever be able to create a cron job again?

$ sudo ls -la /var/spool/cron/crontabs
total 12
drwx-wx--T 2 root crontab      4096 Sep 25 03:23 .
drwxr-xr-x 5 root root         4096 Sep 23 00:05 ..
-rw------- 1 root my-user-name  188 Sep 25 03:23 my-user-name

@Gilles Well I've made a lot of progress. I got rid of all the error weirdness by reinstalling cron. Now everything works just as it should when I use

$ crontab -e

except that the script I've been using for years doesn't run.

But another script does run; so I'm lost.

Here's what I've got right now:

$ crontab -l
* * * * * env DISPLAY=:0.0 /home/my-user-name/wallpaper_changer.sh
* * * * * date >> /home/my-user-name/crontest.txt

(I didn't include the 20-odd lines of comments that precede the cron jobs.)

The date job runs exactly as it should but the wallpaper_changer.sh job doesn't do anything. I've used this for years and now it doesn't work. The script works fine from the command line and used to work fine from cron.

$ ls -l /home/my-user-name/wallpaper_changer.sh
-rwxr-xr-x 1 my-user-name my-user-name 694 Jun  2 14:30 /home/my-user-name/wallpaper_changer.sh

$ echo $DISPLAY
:0.0

What's up with this?

  • it sounds to me like something is scanning /tmp and resetting permissions or ownerships – Jeff Schaller Sep 23 '16 at 17:16
  • Downgrading is not officially supported. Something specific to Mint 18 must have crept into a configuration file somewhere. This is possibly related to the location of temporary files. Post the output of echo "TMPDIR=$TMPDIR"; ls -ld /tmp "$TMPDIR" "$(mktemp -d)" – Gilles Sep 23 '16 at 20:14
  • @Gilles: echo "TMPDIR=$TMPDIR"; ls -ld /tmp "$TMPDIR" "$(mktemp -d)" TMPDIR= ls: cannot access : No such file or directory drwxrwxrwt 15 root root 4096 Sep 24 11:27 /tmp drwx------ 2 my-user-name my-user-name 4096 Sep 24 11:27 /tmp/tmp.6QGdOkrYg4 – Don Nadie Sep 24 '16 at 14:39
  • Everything looks normal with temporary files in general so I guess the problem is with cron. Does crontab -e work (editing root's crontab, which is neither your crontab nor the system crontab)? What's the output of sudo ls -la /var/spool/cron/crontabs ? – Gilles Sep 24 '16 at 17:20
  • @Gilles: $ sudo ls -la /var/spool/cron/crontabs total 12 drwx-wx--T 2 root crontab 4096 Sep 25 03:23 . drwxr-xr-x 5 root root 4096 Sep 23 00:05 .. -rw------- 1 root my-user-name 188 Sep 25 03:23 my-user-name – Don Nadie Sep 26 '16 at 17:02
2
$ sudo ls -la /var/spool/cron/crontabs
total 12
drwx-wx--T 2 root crontab      4096 Sep 25 03:23 .
drwxr-xr-x 5 root root         4096 Sep 23 00:05 ..
-rw------- 1 root my-user-name  188 Sep 25 03:23 my-user-name

The ownership of /var/spool/cron/crontabs/my-user-name is wrong. You should be the owner. That would explain why cron can't overwrite the file. Also the file would normally be in crontab group but I don't think it matters.

You can fix this by running

sudo chown my-user-name /var/spool/cron/crontabs/my-user-name

I don't know what could have caused this and I don't see how it could be related to a system downgrade. The underlying issues might cause other problems.

  • Thanks for trying, but the problem remains as before. First I tried sudo chown my-user-name /var/spool/cron/crontabs/my-user-name so that $ sudo ls -la /var/spool/cron/crontabs total 12 drwx-wx--T 2 root crontab 4096 Sep 25 03:23 . drwxr-xr-x 5 root root 4096 Sep 23 00:05 .. -rw------- 1 my-user-name my-user-name 188 Sep 25 03:23 my-user-name and got $ crontab -e Temporary crontab no longer owned by you. Error while editing crontab – Don Nadie Sep 29 '16 at 12:01
  • Then I tried $ sudo chgrp crontab /var/spool/cron/crontabs/my-user-name so that $ sudo ls -la /var/spool/cron/crontabs total 12 drwx-wx--T 2 root crontab 4096 Sep 25 03:23 . drwxr-xr-x 5 root root 4096 Sep 23 00:05 .. -rw------- 1 my-user-name crontab 188 Sep 25 03:23 my-user-name and got $ crontab -e Temporary crontab no longer owned by you. Error while editing crontab again. When nano starts, there's no crontab template with a bunch of commented lines. Everything goes south just as in my previous comments. – Don Nadie Sep 29 '16 at 12:09
  • @DonNadie Hmmm. I don't know. Please test whether crontab -e works as root, and create a new test user and test whether crontab -e works as that user. – Gilles Sep 29 '16 at 12:29
  • 1
    @DonNadie Edit your question, not my answer. – Gilles Sep 29 '16 at 16:44
1

You need to edit permissions on the crontab binary and set them back to what they are when you do a fresh install.

NOT WORKING permissions:

ls -la /usr/bin/crontab
-rwsr-xr-x 1 root crontab 40264 Oct  7  2017 /usr/bin/crontab

Action, do as root or using sudo:

chmod g+s /usr/bin/crontab
chmod u-s /usr/bin/crontab

WORKING permissions:

ls -la /usr/bin/crontab
-rwxr-sr-x 1 root crontab 40264 Oct  7  2017 /usr/bin/crontab

Taken from a fresh working installation, the working permissions are set during installation.

No idea why they changed later on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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