[ale] klogd and syslogd hanging

[Doug McNash]

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
>