LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   booting slackware may get stuck during syslogd. an explanation and a fix (http://www.linuxquestions.org/questions/slackware-14/booting-slackware-may-get-stuck-during-syslogd-an-explanation-and-a-fix-941189/)

nass 04-22-2012 05:56 PM

booting slackware may get stuck during syslogd. an explanation and a fix
 
hello everyone,
at this point what I am about to discuss has happened to me in 3 different slackware pcs and I have somewhat seeked help in the past http://www.linuxquestions.org/questi...yslogd-852627/ but had no luck.
I imagine, since I am the one with that problem and I had it in more than one computer, I am doing some systematic error, which i'm yet to pin point.

However, since I did figure out (finally) what causes syslogd script to lock up during boot I will share it here, perhaps there is something that could be changed in the rc.syslog init script.

Ok so the script locks up in a while loop:
Code:

      while [ ! -e /dev/log ] ; do
        sleep 0
      done

so it can't find the /dev/log - no excitement here.

The reason for that is that /usr/sbin/syslogd fired up and exited right away giving no informative message (thus the headaches and riddle for me).

rebooting in single mode, eventually led to the answer: the folder /var/run was missing and apparently the syslogd needs to place its /var/run/syslogd.pid file there. bummer.
The syslogd doesn't say anything (unless you run it with the -n option) and running with debug output (-d) doesn't create the pid file and so syslogd starts correctly (thus eliminating any chances of getting a meaningful msg from there too).

I order to overcome this lack of /var/run folder I added the following in the rc.syslogd script

Code:

syslogd_start() {
  if [ -x /usr/sbin/syslogd -a -x /usr/sbin/klogd ]; then
    echo -n "Starting sysklogd daemons:  "
    echo -n "/usr/sbin/syslogd "
    if [ ! -d /var/run ] ; then
      mkdir /var/run
    fi

    /usr/sbin/syslogd
    # prevent syslogd/klogd race condition on SMP kernels
    ...
    ...

my system is back to booting normaly and properly, but a few questions come to mind:

1) who deleted the /var/run folder?
2) should I check for the existence of the /var/run folder somewhere else instead of the rc.syslog script?
3) should (perhaps) the rc.syslog script be modified to account for this weakness in syslogd executable?

especially for 1) i've been trying to figure out what might be causing it.
of course i don't have any cron jobs tampering with /var/run . The system is a slack32 v13.37 (had the very same problem with a v13 and a v11).
The only additional packages I have installed (from slackbuilds) are: htop, ulogd, webmin, wol. of all these packages, only ulogd existed in all 3 pc's that failed.
The kernel is a modified generic 2.6.37.6 (just added a few things , nothing removed)

I seriously can't imagine what could cause the /var/run folder to disappear - unless it is always deleted by a slackware process i am unaware of.
Anyone, has ANY clue?

Thank you for your help

willysr 04-22-2012 06:06 PM

/var/run is created when you install aaa_base package, so if you happened to perform full install, you will get the directory on your system.

You might want to check if you happened to delete the directory accidentally in the past

Woodsman 04-22-2012 06:56 PM

That is a reasonable solution.

Who knows what or who deleted /var/run. Most of us have seen anomalies like that and although knowing what or who deleted the directory is nice, sometimes the best approach is shrug and do as you did with a simple script edit.

Considering how many processes depend upon /var/run, I wonder why none of them complained. Would be interesting to create a test system with no /var/run and see what complains.

Considering that dependence, I think the answer to your second question is yes: sooner is better. Check your /etc/inittab, but the first rc.d script to run on a stock Slackware is rc.S.

With that said, there is a snippet in the rc.S script that performs some system cleanup, which includes the /var/run directory. Look toward the end of the rc.S script for the comment "Clean up some temporary files."

As written, the rc.S snippet should not be deleting /var/run in entirety, only files and directories underneath. Perhaps some weird "corner case" in another script on your system causes a complete directory deletion.

Possibly right after that cleanup snippet in rc.S, you add your /var/run existence test rather than in rc.syslog. Like this:

AS IS:

Code:

# Clean up some temporary files:
rm -f /var/run/* /var/run/*/* /var/run/*/*/* /etc/nologin \
  /etc/dhcpc/*.pid /etc/forcefsck /etc/fastboot \
  /var/state/saslauthd/saslauthd.pid \
  /tmp/.Xauth* 1> /dev/null 2> /dev/null
  ( cd /var/log/setup/tmp && rm -rf * )
  ( cd /tmp && rm -rf kde-[a-zA-Z]* ksocket-[a-zA-Z]* hsperfdata_[a-zA-Z]* plugtmp* )

CHANGE TO:

Code:

# Clean up some temporary files:
rm -f /var/run/* /var/run/*/* /var/run/*/*/* /etc/nologin \
  /etc/dhcpc/*.pid /etc/forcefsck /etc/fastboot \
  /var/state/saslauthd/saslauthd.pid \
  /tmp/.Xauth* 1> /dev/null 2> /dev/null
  ( cd /var/log/setup/tmp && rm -rf * )
  ( cd /tmp && rm -rf kde-[a-zA-Z]* ksocket-[a-zA-Z]* hsperfdata_[a-zA-Z]* plugtmp* )
if [ ! -d /var/run ] ; then
  mkdir /var/run
fi

Or add the same directory existence test in your rc.shutdown script. Or both. :)

nass 04-23-2012 03:07 AM

willysr, i'm sorry, i should have been a little more elaborate.
All my troubled installations were full installs so the /var/run folder was there after the initial install.
in fact all the systems would run fine for a period of time (ranging from a few weeks to a few months) and then all of a sudden they wouldn't boot after a reboot.

woodsman
Quote:

Considering how many processes depend upon /var/run, I wonder why none of them complained.
The reason is that the system would never boot - so nobody else got the chance to complain.
If I do however start the syslogd in debug mode (as syslogd -d &) the /dev/log gets created but many of the consequent start up processes complain about not being able to write to the logging facilities (or something like that)

I shall move the mkdir command to rc.S and rc.shutdown
and I come to believe that It could be ulogd's fault so i'll keep an eye out for that.
I'm pretty sure that I have never fiddled around with /var/run folder ever in my tweaks.


All times are GMT -5. The time now is 09:45 PM.