crontab -e no longer working; old crontab running

crond is the cron daemon, so that's the service that would be restarted.

/etc/init.d/crond restart

It seems odd you'd be having problems with crontab -e.

Have you modified the path of /bin/vi, your local PATH, or anything of the like?

@Ashiyah:

crond is the cron daemon, so that's the service that would be restarted.

/etc/init.d/crond restart

It seems odd you'd be having problems with crontab -e.

Have you modified the path of /bin/vi, your local PATH, or anything of the like?

It may actually be named cron (or even something else) rather than crond.

As for the original question:

Is there no output at all when running crontab -e?

What does "type crontab" say? (Do you have some aliases or something like that involved?)

If not, maybe throw strace at it and see if that reveals anything of interest?

Also, have you set EDITOR, VISUAL or some other related environment variable to something funky?

No output at all. just brings me back to the prompt. "type crontab" tells me "crontab is /usr/bin/crontab"

vi is in usr/bin (symbolic link to etc/alternative–that is, as per original config).

I wouldn't be entirely suprised if I didn't muck up PATH in attempting to get the cronjob in the crontab working--that is, in the "old bad crontab". So perhaps if I "cron restart", I'll sort that out too. But it SEEMS ok. echo $PATH got me: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:bin.

I also had tried previously to "reset" EDITOR to vi, thinking then I had already done something and that would bring it back/fix the crontab -e issue. But maybe I just didn't execute correctly? How should it be done on Debian?

And thanks for help thus far!

On Debian, you can select your default editor with the following command:

update-alternatives --config editor

Btw, do you find anything if you run this command?

ps aux | grep -i cron

@NeonNero

running that command returns````
root 5365 0.0 0.0 1860 940 ? Ss Aug01 0:00 /usr/sbin/cron
root 22608 0.0 0.0 3928 544 hvc0 S+ 16:38 0:00 grep -i cron

I did try a cron restart from the etc/ directory as noted above, but same cron daemon error from same "nonexistent" crontab file.

Do I actually need to try to issue the restart from /user/sbin?

And is that````
update-alternatives --config editor 

? or````
update-alternatives --set editor /usr/bin/vim

````? Not familiar with what config editor will do–although admit not all that familiar with most of this.

@kweiss:

And is that update-alternatives --config editor ? or````
update-alternatives --set editor /usr/bin/vim

````? Not familiar with what config editor will do–although admit not all that familiar with most of this.
The –config editor version will let you pick the editor name from a list, rather than digging up the path. On one of my servers, update-alternatives –config editor brings up the following:

<code>There are 4 choices for the alternative editor (providing /usr/bin/editor).

  Selection    Path                Priority   Status
------------------------------------------------------------
  0            /bin/nano            40        auto mode
  1            /bin/ed             -100       manual mode
  2            /bin/nano            40        manual mode
* 3            /usr/bin/vim.basic   30        manual mode
  4            /usr/bin/vim.tiny    10        manual mode

Press enter to keep the current choice[*], or type selection number:</code>

Well, my editor is vim.basic now, but I still can't get crontab -e to do anything other than return a prompt. On issue of getting the "new" crontab recognized, I tried restart from /usr/sbin but just got following message````
can't lock /var/run/crond.pid, otherpid may be 5365: Resource temporarily unavaialable

Any other suggestions? Should I just

kill -9 5365
````–which I can't see in top but apparently it's running--or will that cause some yet further problem?

And thanks for the --config editor tip, even if didn't get me into crontab. Just no clue why crontab -e or -any other variable just does absolutely nothing--and not seeing problem show up on any forums.

You probably don't want to 'kill -9' anything unless a normal 'kill' won't do it; it's the difference between asking someone to leave the premises immediately and shooting them in the head without warning. You also want to have cron running – there's a lot of regular maintenance tasks that go on in the background.

The 'crontab' command operates distinctly from the cron daemon itself. What does 'crontab -l' report? You might also want to try 'apt-get install cron --reinstall' (I think…) to force a reinstall of it, in case the binary got eaten.

I get nothing with crontab -anything. All just bring me back to the prompt -e , -l, -r . There is no apparent action (certainly nothing displays on screen).

If the "cron" I'm killing is the usr one not the system one, isn't the only cron jobs I'd be stopping those in crontab? And couldn't I just restart (or start) cron after the kill anyway (would kill the specific PID, which says it is cron in /usr/sbin)?

It just seems that the restart I tried earlier did not get the system to "see" the new crontab–seems like wherever (var/spool/cron/crontab/root?) crontab is really running from is locked in on my old crontab (some corruption possibly, as you say, somewhere along the line of when I was trying to redo it in the first place).

With vi or nano I can make a pretty little crontab file, but until I can write it anew the proper way via crontab or edit it with crontab -e, it seems it's just a file that means nothing and isn't executed no matter how much I restart cron.

Do you think a cron reinstall would "flush out" any memories of old crontab jobs?

Or is it as stupid or simple as moving the crontab I have written into a different directory, and then a restart will "find" it and use it vs the old one in memory? (to be clear: if I "find", the ONLY crontab that comes up is the new one I wrote that I have now in /usr/bin--so as root, only one crontab file exists--the new one, not the old one generating the errors and so apparently running via cron as that PID).

Please excuse any inaccuracies in terminology or description--I am very, very much a newbie.

And I very much appreciate the suggestions and help!

UPDATE: I tried to reinstall cron and got Err http://ftp.debian.rog lenny/main cron 3.0p11-1005 404 Not found [IP xxetc] Failed to fetch http://ftp.debian.org/dbian/pool/main/c/cron/cron_3.0p11-1005_amd64.deb 404 not found [IP xxetc] E: Unable to fecth some archives, maybe run apt-getupdate or try with --fix-missing? Needless to say, crontab -e still not working after that. Hopefully I haven't also now somehow made things worse.

What if I tried to delete the "root" entry in /var/spool/cron/crontabs ? Theoretically all that is is my "bad" crontab file.

Any unintended consequences for that–assuming the system will let me delete it?

Someone suggested I see what I get after these````
echo $VISUAL
echo $EDITOR
ls -lah /usr/bin/editor
ls -lah /usr/bin/sensible-editor

I got nothing after the echos and

root root /usr/bin editor -> /etc/atlernatives/editor

and

root root /usr/bin/sensible-editor

after the other 2.

I took it upon myself to````
EDITOR=/usr/bin/sensible-editor  and export the same and repeat for VISUAL

.

But either that was wrong, too–or just still not underlying problem. crontab -e still does nothing.

Don't get, either, why echo showed no editor, when I had used the --config (as noted above) to select vim.basic (was on nano, both + and *).

Holding off on other suggestion of doing apt-get update, then trying reinstall. Not sure if I"m just making something worse.

Still open to ideas or if I should go ahead and try apt-get update cron and then reinstall.

> if I "find", the ONLY crontab that comes up is the new one I wrote that I have now in /usr/bin

!

So, you replaced /usr/bin/crontab with something else? Yup, that'd do it.

And it also sounds like you're running Debian Lenny – it was end-of-life'd 6 months ago. You can probably point apt at archive.debian.org to be able to reinstall cron, but you're going to want to consider upgrading or reinstalling very soon.