crontab lost

That should be Ubuntu 10.10 not 101.10!

What is the output of:

service cron status

Thanks

cron start / running, process 897

Ok it's running. If you run:

export EDITOR=nano; crontab -e

Do you see your cron job?

Yes!

Though perhaps I should add that it appears not to have run last night, which is why I started looking.

So I copied the information from the 'export' version of crontab, ran 'sudo crontab -e' and pasted the info into this version and saved it. Now if i run 'sudo crontab -l' I get "cron: can't lock /var/run/crond.pid, otherpid may be 982: Resource temporarily unavailable" so things still apear to be screwed up.

Try:

sudo service cron stop; sudo service cron start

This will make cron stop then start and will give it a new PID. May help (Test with the sudo crontab -l as you did earlier)

peter@Acer-2:~$ sudo service cron stop; sudo service cron start
[sudo] password for peter:
cron stop/waiting
cron start/running, process 1876
peter@Acer-2:~$ sudo cron -l
cron: can't lock /var/run/crond.pid, otherpid may be 1876: Resource temporarily unavailable

The command to check root's scheduled tasks is

sudo crontab -l

whereas you ran

sudo cron -l

which accounts for the error message. Try:

sudo crontab -l

You are so right!

OK so Now I am all fixed up again, thanks - but, back to my original question -

"Is there some reason why this may happen? That is preventable?"

Where is the crontab file supposed to be located? The location offered by the editor, and which I have always accepted is currently:

/tmp/crontab.vtazMY/crontab

Is the "tmp" here a clue as to why it disappeared?

"Is there some reason why this may happen? That is preventable?"

Perhaps it has something to do with the specific task in your crontab (rather than arising from a failure of cron itself). Can you post the crontab's contents here?

"Where is the crontab file supposed to be located?"

The systemwide crontab is at /etc/crontab. Individual user's crontabs are located inside /var/spool/cron/crontabs. (But you can only look inside that directory as root. So for example, if you wanted to be able to cd to that directory on the command line, you could run "sudo -s" first to get a root shell. As long as you see # instead of $ in your shell prompt, you're still in the root shell--to get out of the root shell, run the "exit" command.)

The best way to view, edit, and otherwise manager individual users' crontabs is with the crontab command.

"Is the "tmp" here a clue as to why it disappeared?"

No. When you edit a crontab with "crontab -e", it makes a copy of the crontab, you edit the copy, then when you're done it updates the crontab from the copy. This is to avoid unnecessary crontab breakage and/or incorrect actions being performed, while you are in the process of editing the crontab. The idea is that if you edit a crontab with "crontab -e", none of the changes are applied until you've saved the file *and* closed the editor.

I do think I know what is responsible for the "disappearance." Before, you had run "crontab -e", which edits the crontab associated with your personal user account (or rather, with whatever user account you're using). But then, later, you ran "sudo crontab -l" which lists the root user's personal crontab, rather than your own. You should probably not have used "sudo" for this--since you saw the contents of your crontab when you ran "crontab -e" without "sudo" at the beginning, the tasks you're running are probably from your user account's crontab.

I should probably have mentioned that when I corrected your command from "sudo cron -l" to "sudo crontab -l". The command "sudo crontab -l" was a correctly formed command...but it probably didn't *do* what you wanted.

By the way, the root user account crontab should not be confused with the systemwide crontab. They both run commands as root and they both require you to be root to edit them, but they are separate crontabs. You should, generally speaking, not use the root account's crontab--administrative tasks that cannot or should not be performed in individual users' crontabs should be performed by the systemwide crontab (/etc/crontab). If you ran "sudo crontab -e" then I recommend you list the contents of root''s crontab with "sudo crontab -l". If it says "no crontab for root" you're fine, and if it lists actual entries then root's crontab is probably actually being used. But if it lists nothing (as if you had run no command at all), then for the sake of tidiness you may want to remove it with "sudo crontab -r".

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h dom mon dow command
#

30 2 * * 1 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/1 Terra-Seagate/DatBUMon'
30 2 * * 2 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/1 Terra-Seagate/DatBUTue'
30 2 * * 3 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/OneTerra/DatBUWed'
30 2 * * 4 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/1 Terra-Seagate/DatBUThur'
30 2 * * 5 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/OneTerra//DatBUFri
30 2 * * 6 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/1 Terra-Seagate/DatBUSat'
30 0 * * 0/3 rsync -a -r --delete -v '/media/1 Terra-Seagate/DatBU3Week02/' '/media/OneTerra//DatBU3Week03'
00 1 * * 0/3 rsync -a -r --delete -v '/media/OneTerra/DatBU3Week01/' '/media/1 Terra-Seagate/DatBU3Week02'
30 1 * * 0/3 rsync -a -r --delete -v '/media/ Terra-Seagate/DatBUSun03/' '/media/OneTerra//DatBU3Week01'
00 2 * * 0 rsync -a -r --delete -v '/media/OneTerra/DatBUSun02/' '/media/1 Terra-Seagate/DatBUSun03'
30 2 * * 0 rsync -a -r --delete -v '/media/OneTerra/DatBUSun01/' '/media/OneTerra/DatBUSun02'
30 3 * * 0 rsync -a -r --delete -v '/media/OneTerra/BU/' '/media/OneTerra/DatBUSun01'

Did all the entries fail to run, or just one/some of them? If the latter, which one(s) failed to run? Also, are you sure the volume on why they operate was mounted at the time?

Eliah,
Thanks for previous explanation re locations - looks very helpful, but have to digest it and in the middle of too many things just now.
Re your last question, I have not had a problem with the commands running. In fact everything ran for about 10 days, then failed and when I checked, crontab appeared to have vanished overnight - though the export command per "actionparsnip" retrieved it. I suspect this is for the reasons you stated. The failure to operate that night was a missing"'" and an extra "/" in the line above ending "....a//DatBUFri"

So I am begining to think that apart from this command error there was nothing wrong apart from my ignorant change from "sudo crontab -e" vs "crontab -e"