So, I've been looking at this a bit. For background, when starting rsyslog, we create a FIFO file and start a dd process that shovels data from /proc/kmsg to the FIFO. This gets around a permissions issue with /proc/kmsg.
rsyslog then does two things with the FIFO: 1) As root, on startup, it calls open() on the FIFO. This (currently) will block until another process opens the FIFO for writing (see fifo(7)). 2) In a non-privileged thread, it will repeatedly call read() and block waiting for input from the FIFO. It then logs everything it sees. I can maybe see (1) above causing a problem. To fix, we can open it with O_NONBLOCK and then take away O_NONBLOCK after opening so that the threaded read() loop will work as expected. You can trigger this race condition by changing /etc/init.d/rsyslog to do: start-stop-daemon --start --pidfile $KMSG_PIDFILE --exec /bin/sh -b -m -- -c "sleep 15 && /bin/dd bs=1 if=/proc/kmsg of=$KMSG_PIPE" instead of a direct dd (i.e. you sleep before running dd). However, this would explain only a minimal delay. dd opens the output file on start; it doesn't block on input before opening the output. The symptom you're describing, Kees, seems like instead of the dd race, you're getting the read() call in the main parent process (not a thread). But I highly doubt that's actually occurring, given the current code. You only seem to be seeing a block once (after you give kmsg any data, you are unblocked forever), so I don't think rsyslog is actually running that loop. But rather, it really does seems like the open() is blocking on data... Not sure why. Your second issue with the 5 minute sleep looks like the forked main process hit some similar (or same) block and never got around to committing parricide (i.e. never backgrounded). -- hanging during start https://bugs.launchpad.net/bugs/423943 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
