Latest LQ Deal: Linux Power User Bundle
Go Back > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Slackware This Forum is for the discussion of Slackware Linux.


  Search this Thread
Old 04-22-2012, 05:56 PM   #1
Registered: Apr 2006
Location: Athens, Greece
Distribution: slackware, debian, ubuntu
Posts: 648

Rep: Reputation: 38
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 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:
      while [ ! -e /dev/log ] ; do
        sleep 0
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/ 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

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
    # 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 (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
Old 04-22-2012, 06:06 PM   #2
Senior Member
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 3,825

Rep: Reputation: 1101Reputation: 1101Reputation: 1101Reputation: 1101Reputation: 1101Reputation: 1101Reputation: 1101Reputation: 1101Reputation: 1101
/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
Old 04-22-2012, 06:56 PM   #3
Senior Member
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544Reputation: 544
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:


# 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/ \
  /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* )

# 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/ \
  /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
Or add the same directory existence test in your rc.shutdown script. Or both.
Old 04-23-2012, 03:07 AM   #4
Registered: Apr 2006
Location: Athens, Greece
Distribution: slackware, debian, ubuntu
Posts: 648

Original Poster
Rep: Reputation: 38
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.

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.


/var/run folder, boot failure, syslogd

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
stuck wlile booting aggrishabh Linux - Software 1 11-30-2010 09:24 PM
Dual booting Vista and Slackware; How Can I Fix My MBR if I Bust it? Dark Jirachi Linux - General 3 09-16-2007 12:21 PM
Booting Linux gets stuck on IO! angelique84 Linux - Laptop and Netbook 8 01-31-2007 03:06 AM
solaris 2.7 stuck in booting mindcry Solaris / OpenSolaris 5 09-10-2003 07:45 PM
stuck when booting in the GUI niton Linux - Newbie 3 07-30-2002 01:10 AM > Forums > Linux Forums > Linux - Distributions > Slackware

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

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