I have installed this package on my redhat 7.3 server and from then when the
logrotate try to kill -HUP the syslogd, nothing happen, the files in /var/log
are incremented but syslogd continue to fill the same file (for cron, boot.log,
messages, ..). I must restart (/etc/ini.d/syslog restart) to have syslogd change
logging file (that's obvious). Seems that syslogd doesn't handle correctly kill -HUP
Thanks for your help
------- Additional Comments From firstname.lastname@example.org 2004-11-29 03:17:13 ----
I have made a reboot of my server and what a surprise, it did not reboot due to
a change in the /dev/null device. This device was now a file. I don't know if
this is related, but the device /dev/null was rename /dev/null.1 as if it was
changed by logrotate...
I never had any problem before installing this sysklod from fedora.legacy
the boot error message was
configuring kernel parameters : dup2 : bad file descriptor
I have restarted with the rescue disk and changed the /dev/null file to a device
Hope I am alone with this problem
------- Additional Comments From email@example.com 2004-12-21 09:54:26 ----
I suspect the /dev/null has been accidentally put into a logrotate config file,
where it has been rotated, and after that pretty much everything has ceased to
exist for numerous reasons.
In any case, there is not anything particular in the sources between the RHL73
sysklogd and FL*s release to suggest a culprit there, so closing.
------- Bug moved to this database by firstname.lastname@example.org 2005-03-30 18:29 -------
This bug previously known as bug 2311 at https://bugzilla.fedora.us/
Originally filed under the Fedora Legacy product and Package request component.
Unknown priority P2. Setting to default priority "normal".
Unknown platform PC. Setting to default platform "All".
The original reporter of this bug does not have
an account here. Reassigning to the person who moved
it here, email@example.com.
Previous reporter was firstname.lastname@example.org.
Setting qa contact to the default for this product.
This bug either had no qa contact or an invalid one.