LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Suse/Novell
User Name
Password
Suse/Novell This Forum is for the discussion of Suse Linux.

Notices



Reply
 
Search this Thread
Old 01-24-2009, 10:30 AM   #1
ps09973
LQ Newbie
 
Registered: Jan 2009
Posts: 2

Rep: Reputation: 0
crontab Hangs While Trying to Save


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.
 
Old 01-24-2009, 12:47 PM   #2
pcunix
Member
 
Registered: Dec 2004
Location: MA
Distribution: Various
Posts: 149

Rep: Reputation: 23
Quote:
Originally Posted by ps09973 View Post
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.
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..
 
Old 01-24-2009, 12:50 PM   #3
colucix
Moderator
 
Registered: Sep 2003
Location: Bologna
Distribution: CentOS 6.5 OpenSuSE 12.3
Posts: 10,509

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
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?
Code:
# crontab file
beware that this will overwrite any existing crontab, so first backup the output of the command crontab -l somewhere.
 
Old 01-24-2009, 12:57 PM   #4
colucix
Moderator
 
Registered: Sep 2003
Location: Bologna
Distribution: CentOS 6.5 OpenSuSE 12.3
Posts: 10,509

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
Quote:
Originally Posted by pcunix View Post
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
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.
 
Old 01-26-2009, 04:36 PM   #5
ps09973
LQ Newbie
 
Registered: Jan 2009
Posts: 2

Original Poster
Rep: Reputation: 0
Tried it, no Luck

I tried installing a new crontab with
Code:
# crontab file
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?
 
Old 01-26-2009, 05:39 PM   #6
colucix
Moderator
 
Registered: Sep 2003
Location: Bologna
Distribution: CentOS 6.5 OpenSuSE 12.3
Posts: 10,509

Rep: Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957Reputation: 1957
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
Code:
export EDITOR=kwrite
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?
 
Old 01-26-2009, 06:31 PM   #7
ps09973
LQ Newbie
 
Registered: Jan 2009
Posts: 2

Original Poster
Rep: Reputation: 0
Thumbs up

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!
 
Old 03-11-2009, 05:17 PM   #8
randomuser1024
LQ Newbie
 
Registered: Mar 2009
Posts: 1

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

Code:
notify          = "/usr/sbin/audbin -S /var/log/audit.d/save.%u -C";
to

Code:
notify          = "/usr/sbin/audbin -S /var/log/audit.d/save.%u";
and restart auditd.

HTH
 
  


Reply

Tags
cronjob, crontab, sles9


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
replaced crontab, now should get crontab back to what it was raminn Linux - Newbie 2 10-20-2008 08:15 PM
error when i type crontab -e and save rajan.prabhakar Linux - Server 13 10-10-2008 05:50 AM
Crontab -e does not save kiley_rodgers Linux - General 7 01-13-2006 10:59 AM
OpenOffice.org hangs on File > Save eco2geek Suse/Novell 1 01-14-2005 07:15 AM
OpenOffice save button hangs program bobterri Linux - Software 8 01-23-2003 02:39 PM


All times are GMT -5. The time now is 08:10 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration