Bug 13188 - initlog fails when starting syslogd on read-only root file system
Summary: initlog fails when starting syslogd on read-only root file system
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 6.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-06-28 16:38 UTC by fubob
Modified: 2014-03-17 02:14 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-07-17 13:06:46 UTC
Embargoed:


Attachments (Terms of Use)

Description fubob 2000-06-28 16:38:47 UTC
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
 fubob
 Cisco Systems

Comment 1 Leo Bergolth 2000-07-17 13:06:46 UTC
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-30 00:41:52 UTC
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.