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. Reproducible: Always Steps to Reproduce: 1. emerge any package 2. restart sysklogd 1.5 while it's compiling 3. tail -F build.log Actual Results: 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). Expected Results: 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...
