[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Intresting problem (and diald WARNING)



Hello

First a smal warning about diald: If Your etc/diald.ip-up script for some
reason is 'hanging', then will diald keep the link up (this is probably
documented behavior, but I was suprised anyway...). I noticed this
becose my ip-up script was 'hanging' on a pipe to /dev/xconsole. I got
diald work as expected by making /etc/diald.ip-up just bakgrund another
shellscript (doing all the 'real' work). Sadly, that do bring up other
problems... This is the script i do background from /etc/diald.ip-up:

-------------------- /etc/diald.fetch-up ----------------------
#!/bin/bash
#
# Fetch and send mail
#
# Run by diald.ip_up  when diald have conected to internet
# Got 30 sec to complete before killed by diald.fetch-kill!
#
echo -e `date`: Running /etc/diald.fetch-up\\r > /dev/tty8 &
echo -e `date`: Running /etc/diald.fetch-up\\r > /dev/xconsole &
echo `date`":" fetchmail run from diald.fetch-up >> /root/mail-log
#
# Stopp fetchmail if alredy runing (probably a bug).
#
/usr/local/bin/fetchmail --quit -f /root/.fetchmailrc -L /root/mail-log
#
# Starta fetchmail in deamon mode and send qued mail.
#
/usr/local/bin/fetchmail -f /root/.fetchmailrc -b 10 -L /root/mail-log -d 600 
-t 300
runq &
-------------- end /etc/diald.fetch-up ------------------------

Some subprces of this script is hanging, probably the subproces
started by the line:

echo -e `date`: Running /etc/diald.fetch-up\\r > /dev/xconsole &

I suspect this line becose the problem do have something to do with
/dev/xconsole as it only hangs when the xconsole loging is broken.
I don't know what's braeking the xconsole but it happen in the first
day of system uptime (and is OK after a reboot). I do suspect the
cron.daily scripts. More intresting is the side-efects of this
process hanging on xconsole. For some reason cron-jobs starts to
hang when this process hangs. I can't login as root when this happens
but ther's no problems in using existing root-shells. User login is
OK to. If I kill the proces hanging on xconsole all cronjobs do finish
and the system is back at normal (exept xconsole who is still broke).
If I don't kill it the cronjobs keep piling up until the system load
craches the mashine :(

I do work-around this problem by leting /etc/diald.ip-up also
background this script:

------------------ /etc/diald.fetch-kill -------------------------
#!/bin/bash
#
# Kill ev. 'hangin' diald.fetch-up
# * DO NOT USE WITH ISDN CONECTION WITHOUT PRECOTION **
#
# Started by diald.ip_up  when diald have conected to internet
#
# Give diald.fetch-up 30 secs to complete
#
sleep 30
#
# Then kill any remaining diald.fetch-up *twice*!
#
kill `ps -x | grep diald.fetch-up | gawk -- "{print \\\$1}"`
sleep 1
kill `ps -x | grep diald.fetch-up | gawk -- "{print \\\$1}"`
sleep 2
#
# Mean kill any diald.fetch-up *stil* remaining!
#
kill -9 `ps -x | grep diald.fetch-up | gawk -- "{print \\\$1}"`
sleep 1
kill -9 `ps -x | grep diald.fetch-up | gawk -- "{print \\\$1}"`
#
# Hope this is enuf. Don't dear kill anymore as diald might have a new
# *real* conection comming up soon... If You use ISDN it is probably
# far to lait already....
#
---------------- end /etc/diald.fetch-kill -----------------------

This is (so far) keeping my system from craching :) but it is an
ugly work-around. I can live with an broken xconsole but I still
want to know wats realy is wrong with my system. Do You have any
ide:

o Why is xconsole broke? lsattr /dev/xconsole (when it's broke) give:
  lsattr 1.06, 7-Oct-96 for EXT2 FS 0.5b, 95/08/09
  lsattr: Invalid argument While reading flags on /dev/xconsole
  (dont know what it gives when xconsole is working, and I don't
  want to reboot as I am trying to find out if this 'fix' can keep
  my system up for a 'long' time).
o Why is root login broken when an proces is hanging on the broken
  xconsole and why is cronjobs hanging at this time?
o Any sugestions on what to read or what to investigate on my system
  is welcome.

All the cron.daily script on the machine is as installed by Debian
(the standard script has some "find ... rm" lines commented out whit a
referens to a security hole. The other scripts do "find ... rm" call.
Any reason to worry? Where can I read about this security hole?)

I do know this is unexact questions but it is the best I can do. I
had this problem with Debian 1.1 kernnel 2.0.0 and I upgraded to
Debiann 1.2.6 and kernel 2.0.27 in hope it was an 2.0.0 related
problem but the problem did not go away... I use the prebuilt Debian
'install' kernels (no kernel compile). All the cron.daily script on
the machine is as instaled by Debian (the standard script has some
find -> rm lines comented out whit a referens to a security hole.
The other scripts do find -> rm call. Any reason to worry? Where
can I read about this security hole?)

This problem has become more 'intresting' and less 'frustrating' as
I don't need to do bad reboots avery day any more....

Ask if You need to know anything more.

Sorry for my poor english and TIA /Lars
--
   /  / _/_ _/_ Lars Hallberg IT-konsult      Micro++
  /\_/\ /   /   www.micropp.se/lah            www.micropp.se            
 /   Micro++    OOP C++ WWW-Design Utbildning LINUX FreeWare



Reply to: