I have Sysklogd set up to rotate its logs and restart every Sunday at approx. 3:10 AM EST. If I happen to be running an update via emerge at that time and sysklogd restarts, I find syslog entries in the build.log of whichever package happens to be getting emerged at that point in time. The same is true if I emerge a package, and in another console, manually restart sysklogd. When sysklogd takes over, the emerge process seems to hang and the only way out of it is a manual kill. Version 1.4.2 on another server (same arch) does not do this. It should be noted that the effected server is ~x86.
The original build log is over 6 MB, so I've trimmed it and included the part where sysklogd misbehaves only. I'm attaching it below with the output of emerge --info. For the record, the package being emerged in the log is gcc-4.4.1, but it will happen on any package if the package is being compiled when sysklogd restarts.
Steps to Reproduce:
1. emerge any package
2. restart sysklogd 1.5 while it's compiling
3. tail -F build.log
You'll see the message from sysklogd that lets you know it's restarted. If you monitor it long enough, you'll see output from any number of syslog-monitored processes (for confirmation, I included a sample postfix debug stream taking place at the same time). Gcc-4.4.1 did not complete the compile process and, in fact, is still hanging (I've not killed it yet).
Sysklogd should restart normally, keep its log info to itself, and emerge should complete without interuption.
root 5175 0.0 6.5 25740 23416 ? S 00:300:15 /usr/bin/python /usr/bin/emerge --update --deep --quiet world
Created attachment 202050 [details]
build.log, with syslog overflow
Logfile is snipped due to space constraints (was over 6 MB). Original logfile can be provided on request.
Created attachment 202052 [details]
Output of emerge --info, in textfile format.
I tried to replicate this several times and it has not happened to me once using 1.5. It seems to me this could have been a form of misconfiguration WRT /dev/console, or that the "bug" is not a sysklogd bug at all.
I think 1.5 should be the stable version, not 1.4.2, as the klogd from 1.5 works better with current kernels, 1.5 is less vulnerable to DoS attacks, etc...