I'm currently running SLES9 and having a problem while trying to save my crontab. As root, I do the usual "crontab -e" make my changes and then try to save with either ctrl ZZ or wq! I then get the message "crontab: Installing new Crontab" and then it just hangs and never returns to the prompt.

Any ideas are appreciated.

regards.

First, I'd get out of the habit of using "crontab -e". It's bad for several reasons - if EDITOR is mis-set you can find yourself totally
confused and can easily lose your crontab entirely.

I always do

crontab -l > /tmp/root-tab
vi /tmp/root-tab
crontab /tmp/root-tab

Try that..

At first I'd check if the crontab file is actually created and see if the new content is saved. Then you can try to run crontab -e using strace and look for error messages before or immediately after editing the crontab. Note that you can do this as root only, since crontab has suid permission which is not inherited when running after strace.

Another clue: do you get the same behavior if you try to install the crontab from a file? That is, what happen if you write the crontab entries in a text file and use this alternative method to edit the crontab?
beware that this will overwrite any existing crontab, so first backup the output of the command crontab -l somewhere.

This is debatable, since a good habit could be simply check the value of the EDITOR variable and eventually set it at login once and for all. Furthermore, very long cron tabs should be always backed-up in a production environment. The really bad habit is that of people editing the /var/spool/crontab files directly as root.

I tried installing a new crontab with but the same behavior resulted (hangs and doesn't return to the prompt).

I also strace'd it a couple of times and noticed the following lines at the end:

0.000080 read(6, "", 4096) = 0
0.000043 write(5, "# DO NOT EDIT THIS FILE - edit t"..., 805) = 805
0.000085 ftruncate(5, 805) = 0
0.000048 lseek(5, 0, SEEK_SET) = 0
0.000041 read(5, "# DO NOT EDIT THIS FILE - edit t"..., 4096) = 805
0.000088 lseek(5, 805, SEEK_SET) = 805
0.000075 lseek(5, 805, SEEK_SET) = 805
0.000062 read(5, "", 4096) = 0
0.000049 read(5, "", 4096) = 0
0.000042 fchown(5, 0, 4294967295) = 0
0.000048 fchmod(5, 0600) = 0
0.000048 close(5) = 0
0.000078 munmap(0x2a9557b000, 4096) = 0
0.000051 rename("tabs/tmp.lOjpVv", "tabs/root") = 0
0.000148 ioctl(3, 0x8028406f

Don't know how to read the file, but it appears that the temp file is being created but then the last line is incomplete.

I also noticed that when I "ps -ef" I have a quite a few "/USR/SBIN/CRON". Also, I noticed all the crontab temp files in /tmp after the system hangs. This appears to be a permissions issue, but haven't nailed it down yet.

Any other ideas are greatly appreciated?

The ioctl call stats for control device. From the ioctl man page: the ioctl() function manipulates the underlying device parameters of special files. In particular, many operating characteristics of character special files (e.g., terminals) may be controlled with ioctl() requests. The argument d must be an open file descriptor.

Anyway, from the posted output it is not clear which device is associated with file descriptor 3. Can you post the whole output of strace? Another test you can try in order to isolate the real problem is to try another EDITOR to write the crontab, specifically one not tied to the terminal, e.g. kwrite. Just set
before running crontab -e and see what happens when you save and quit the GUI editor. Moreover, is this behaviour the same if you run as root and as a local user?

Ahh, getting closer - I'll spare you the entire strace log, but I did find the following line which gave me a clue:

open("/dev/audit", O_RDWR) = 3

So I stopped the audit subsystem, tried "crontab -e" with no hanging this time. The "/USR/SBIN/CRON" processes are also gone.

I'll follow the "audit" trail now.

I Appreciate your help pcunix!

The solution is to change a line in /etc/audit/audit.conf:

to

and restart auditd.

HTH