Bug 13188 - initlog fails when starting syslogd on read-only root file system
initlog fails when starting syslogd on read-only root file system
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-28 12:38 EDT by fubob
Modified: 2014-03-16 22:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-17 09:06:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description fubob 2000-06-28 12:38:47 EDT
The initlog.c line 187 causes syslogd to fail
when the root file system is mounted read-only.
Removing the call to access ("/", W_OK) solves the problem.

We recently switched to a read-only root file
system on some of our boxes in order to have 
very strict guarantees of integrity.  We noticed
that syslog no longer worked after making / read-only.
That is, no log messages appeared in /var/log/messages.  All the normal 
places (/var/log, /dev, etc) are read-write.

We found that on our read-only root, minilogd would always be 
in the background after runnning /etc/rc.d/init.d/syslog start.
This is odd because minilogd should exit as soon as syslogd starts.

Here's what we think happens.  In the normal read-write case,
initlog forks off and execs minilogd.  minilogd unlinks /dev/log
and waits for syslogd to start.  Eventually syslogd unlinks /dev/log
which causes minilogd to exit its event loop.  Everything works fine.

In the read-only case, it seems that minilogd starts *after*
syslogd (the argument to initlog -c) starts.  So syslog unlinks
/dev/log, listens for DGRAMs, then minilogd unlinks /dev/log
and waits for syslogd to unlink /dev/log.  So the problem is that
minilogd cannot start after syslogd, otherwise the programs get
confused.  It appears that minilogd and syslogd are racing to
have control of /dev/log.  In the normal case, minilogd
will win the race.  But if syslogd should win the race, then
minilogd blindly unlinks /dev/log which syslogd is already accepting
DGRAMs on.


We're not sure why you have the call to access ("/", W_OK) in the
first place.  You're not writing to /.  What is the purpose
of this call?  Do you really mean to check access ("/dev/, W_OK)?

Thanks.

-Kevin Fu
 fubob@cisco.com
 fubob@mit.edu
 Cisco Systems
Comment 1 Leo Bergolth 2000-07-17 09:06:46 EDT
I had exactly the same problem and spent half a day tracking it down to the
access("/", W_OK)
line in initlog.c instead of looking into the bug database. :(

I agree with your theory, it looks like a race creating /dev/log.
Checking for access to /dev instead of / fixes the problem if /dev is a seperate
(rw)-filesystem.

--- src/initlog.c.orig  Sun Jul 16 19:40:23 2000
+++ src/initlog.c       Sun Jul 16 19:40:38 2000
@@ -192,7 +192,7 @@
     /* Don't log empty or null lines */
     if (!logEnt->line || !strcmp(logEnt->line,"\n")) return 0;
     
-    if  ( ((stat(_PATH_LOG,&statbuf)==-1) ||(access("/",W_OK)==-1))
+    if  ( ((stat(_PATH_LOG,&statbuf)==-1) ||(access("/dev/",W_OK)==-1))
          && startDaemon()
        ) {
        DDEBUG("starting daemon failed, pooling entry %d\n",logEntries);

Cheers,
--leo
Comment 2 Bill Nottingham 2001-01-29 19:41:52 EST
This is already fixed in the current minilogd.

Note You need to log in before you can comment on or make changes to this bug.