VISUAL=gvim makes crontab -e open a new crontab instead of a current one
My VISUAL setup interferes with my cron jobs.
-
crontab -lworks all right, I see my previous jobs. -
crontab -e,crontab -e -u user-here- opens GVIM on an empty file - checked cron.allow or .deny, nothing, did add cron.allow with my user, nothing changed
- 1 and 2 are even AFTER I've added my user to
crontabgroup -sudo usermod -aG crontab user-here. This made it see the/var/spool/cron/crontabsdir (but not the user crontab file inside?). -
sudo crontab -e -u user-here- opens Vim on my desired file that's the workaround fellas, not a fix, but gets the job done -
vim /var/spool/cron/crontabs/your-user-hereworks and opens the file as expected, allows edition, but then you have tokill -1 your-cron-demon-here, or sent the SIGHUP another way, so cron process knows to re-check config files. A much worse workaround.
So, now I know it's the editor setup. Cron looks at two variables VISUAL and EDITOR, so I checked my configs and sure, I had VISUAL set (VISUAL=gvim). I've reset it, opened a new terminal and nothing.
Works as I want crontab -e to work
sudo crontab -e -u your-user-hereVISUAL=""; crontab -e
How to "fix" visual editor so it opens my crontab, and not an empty one?
1 answer
Specific answer: Use gvim -f.
General answer: Use the non-forking mode of your editor, i.e. if you run it in a terminal, it should wait until the editor is closed to return back control to you.
Explanation
Look in crontab.c, starting at switch (pid = fork()) line.
Cron creates a temporary file for you to edit its contents. Then it forks.
The child process exec's your editor of choice.
The parent process waits on the child process to terminate via wait/waitpid. Now, some GUI editors (of which Gvim is an example) fork to release control of the shell back to the user. So wait/waitpid returns as soon as that happens, and Cron considers that you finalized editing the temporary file, removes it, and at the point Gvim gets to actually load it, Cron was most likely faster and the file doesn't even exist anymore (this is racy though), at which point you get "... no changes made to crontab" or "No modification made" in stderr.
The exact message depends on whether your distribution patches Cron, such as Debian with Allow-editors-with-tmpfiles.patch.
Side note 1: This is probably something worth reporting upstream or to your distribution as non-obvious behavior to be, if not fixed, documented.
Side note 2: That's certainly not the last program you will encounter that expect a non-forking editor.
0 comment threads
0 comment threads