CRON Entry disappeared (effect of ps -eflx?)

[Alzhy]

An account is complaining its cron entries just disappeared. Said account is logged in to concurrently many times (many users use/login to the same account concurrently) and no one can specifically recall what was done except the chorus was that the cron entries for the account disappeared. I checked the crontab file and indeed it is zero.

I've looked at the shell history and one entry was :

ps -eflx|cron

Could this be a plausible explanation for the account's crontab disappearance? What other circumstances would render the disappearance of a cron entry apart from a "crontab -d"? Would two sessions doing a "crontab -e" also null the account's crontab entries?

[John Poff]

Hi Nelson,

That's a strange one. I tried it on a test box here and your 'ps' command didn't nuke my crontab, but I guess anything is possible.

Was the crontab file for the user (/var/spool/cron/crontabs/) completely missing or was it just nulled out (zero bytes). If the file is zero bytes you might get a clue from the date/time stamp on it.

JP

[Alzhy]

just nulled.

No record at all in command history of both root and the account that it was nulled out. There are however entries for edits done as there were several "crontab -e" commands registered.

In the past I observed this account to have more than one crontab -e session opened.

[Rick Garland]

Something I have done and you can search for in the history...

When modifying the crontab, the user invokes using 'cron -e'. For removing cron entries use 'cron -r'. NOTE, the 'e' key and the 'r' key are right next to each other. Very easy to 'fat-finger'

[Alzhy]

Rick... if it were an accidental/inadvertent "crontab -r" - then the crontab file would have been completely wiped out. It is not.. it is simply null and rid of the many cron entries it reportedly had.

[Pete Randall · Accepted solution]

Nelson,

I did some experimenting with the simultaneous crontab -e sessions. The only way I can see that nulling things out is if the sessions were ended simultaneously. If they end sequentially, the last one wins.

The only other explanation I can think of is that someone made a finger check in their editing and ended up writing out a null file.


Pete

[Steven E. Protter]

No Nelson, that does not seem a plausible explanation to me.

Something else had to happen.

Perhaps the /var filesystem got full or something.

SEP

[Bill Hassell]

I kmake it a point to NEVER use crontab -e, especially with multiple users logging in to the same account (like root). Loss of the crontab file is a pain to fix so crontab -e is forbidden. Instead, a crontab file is kept in $HOME, ideally in a subdirectory like crontab.safe or something similar. The file itself is usually called crontab.root or crontab.current and is created for the first time with:

crontab -l > $HOME/crontab.safe/crontab.current

Then any change to crontab is made by first using diff to compare the output of crontab -l with crontab.current...if different, time to talk to the users again and remind them of the process. Then edit crontab.current and finally: crontab crontab.current

That way, a completely separate copy of crontab is maintained in a well-know place and accidental changes are harder to make.

[A. Clay Stephenson]

I, like Bill never use crontab -e but instead use crontab -l. Almost this same situation came up last week and I suggested crontab -l > mfile followed by crontab < myfile and several others suggested the much "safer" crontab -e. I suspect that what happened was that someone entered simply "crontab" with the terminal as stdin and then triggered an EOF (perhap's Ctrl-D) and crontab then did just what it was told to do.