[ale] klogd and syslogd hanging

Dow_Hurst dhurst at mindspring.com
Wed Jun 8 13:44:17 EDT 2005


Doug, thanks for the ideas!  I played with stty a bit and then tried sync and init 0.  I was able to get the machine shutdown and restarted with syslogd not configured to output to /dev/tty10.  To my surprise, I was still getting messages on tty10!  I searched thru the startup scripts and found that in boot.klog there is a section that uses the /usr/sbin/klogconsole to direct the kernel to send printk messages to /dev/tty10.  So, I'll watch the machine and see if syslog hangs, klog hangs, or nothing.    

How do I find out if it is a pty or a tty?  I have thought that a pty is virtual terminal and a tty was a real serial port.  What is confusing is that the output is seen on virtual terminal 10 by switching with Alt-F10.  So does that mean that it is a pty assigned to a virtual terminal?  Is the /dev/tty10 actual treated as a pty by the kernel since the hardware for a real serial port isn't there in this machine?  How do you track these assignments?  Can you find them in /proc?

Thanks,
Dow


-----Original Message-----
From: Doug McNash <dmcnash at charter.net>
Sent: Jun 8, 2005 12:31 PM
To: Dow_Hurst <Dow.Hurst at mindspring.com>, 
	Atlanta Linux Enthusiasts <ale at ale.org>
Subject: Re: [ale] klogd and syslogd hanging


Looking at tty_io.c (where the message originates) it appears that the tty 
code is waiting for some queue (probably the write queue) to drain before
it finishes the close.  The code also loops forever here printk'ing the 
message (to the console and syslogd) then calling schedule() until the
condition is cleared.  

The problem (I assume) is that the condition is not clearing so your 
machine gets consumed endlessly printing the message. The message should
have been programmed to print only once.  It probably should call sleep 
instead of schedule() but if this code gets run at interrupt it would be 
very bad to call sleep.

There has always been a problem with what to do on a serial port closing 
with data that has not drained.  If it's a pty 

You have two choices:

1) Modify the tty_io.c code and have it exit the loop after a while and/or 
only print the message once.

2) Take action on your tty link to prevent this deadlock.  I would guess 
you are using hardware handshaking and closing the port before the fifo 
has emptied.  If you can wait in the app before closing. 


On Wed, 8 Jun 2005, Dow_Hurst wrote:


> suse 9.1
> kernel 2.6.5-7.151-defaultddd
> syslogd-1.4.1-519
> init level 3
> 
> I have an error message on tty10 (which is an alternate output for syslogd on suse) that is showing infinite messages:
> 
> release_dev: tty10: read/write wait queue active!
> 
> Does anyone know what this means?  The syslogd daemon is running on the CPU and the /var/log/messages are no longer being logged.  I've tried cycling syslogd with the /etc/init.d/syslog restart/stop/start.  I've signaled syslogd and klogd with different signals such as HUP, TER, and KILL.  I've only truly recovered what seems to be normal operation with a reboot.  Two issues come to mind:
> 
> 1.  syslogd can choke with old compatibility libs that don't format the messages to syslogd correctly.
> 
> 2.  Is the tty10 not released due to its current state when syslogd is killed and that is why I am having to reboot to regain control?  Is there a way to first flush tty10 and regain control of it directly?
> 
> 
> I can try running syslogd in debug mode.  This whole issue cropped up in 
mid April.  I just noticed the CPU was under load (this is a lightly loaded production fileserver).  I used top and saw syslogd and klogd showing significant percentage of the CPU so started investigating.  Ended up frustrated and having to reboot.  Now I've had a second occurence so after more investigation on my own, I ended up rebooting again.  I've seen the third time just 1 day later.  I don't want to have to reboot.  I would dlike to fix this!
> 
> Now that I've got a real error message to deal with, I am going to do some Googling.  
> Thanks for your thoughts,
> Dow
> 
> 
> No sig.
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
> 
_______________________________________________
Ale mailing list
Ale at ale.org
http://www.ale.org/mailman/listinfo/ale


No sig.



More information about the Ale mailing list