Bug 400661

This appears to already be in CVS; assigning so I remember to tag the bug in 
the update.

Marking them as conflicts is possibly not the right approach if the underlying
problem is a logrotate config file conflict.  If somebody loads syslog-ng does
that really mean that they need 'no' functionality provided by the current
rsyslog rpm (which does more than the rsyslogd daemon) ?

Seems to me that fixing the logrotate duplicate config file problem in the
config files in the syslog-ng and rsyslog rpms is a better approach.

The only way I can think of not-conflicting with other syslog packages is to 
create a new syslog-logrotate package that we each require.  Otherwise, I'm 
not familiar with any logrotate configs that would keep us from rotating the 
files more than once.

syslog-ng-2.0.7-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update syslog-ng'

syslog-ng-2.0.7-1.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update syslog-ng'

syslog-ng-2.0.7-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

syslog-ng-2.0.7-1.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Now my systems with syslog-ng report:

  Error: syslog-ng conflicts with rsyslog
  Error: rsyslog conflicts with syslog-ng

and yum updates stop happening.  This might be cause widespread breakage.

It also doesn't seem to fit the standard model that if I want to run one package
I need to put an excludes in for another.  Doug's comment on #3 seems like the
more elegant redhat-ish solution that would avoid the above problems.

Re-open this, or file a new bug?

I've added a new bug: bug#429958.  I'll try to get the rsyslog maintainer CC'd 
and see where we can go from there.

This is really bad.  The syslog-ng should be uninstalled prior to the update. 
And I really don't know how to inform users that they should do this.  Hopefully
comps for F-9 have been changed so we don't run in the same situation in F-9.

Tomas - do you mean permanently uninstall syslog-ng or that if it's temporarily
uninstalled that will get us over the hump?  syslog-ng is still a Fedora package
and offers unique functionality that many folks use.

what functionality does syslog-ng offer that rsyslog doesn't?  I'm really
curious because AFAIK rsyslog was implemented to replace syslog-ng
(http://fedoraproject.org/wiki/Releases/FeatureRsyslog).

syslog-ng has a large user base an is installed on many servers.  Just like 
other software available in Fedora, there doesn't need to be a "one true 
syslog server".

AFAIK, rsyslog was primarily chosen because it offers many similar features to 
syslog-ng while maintaining compatibility with sysklogd's config file, not to 
be a replacement for syslog-ng.

Tomas - sorry, my information was dated.  It looks like rsyslog is now on
feature parity.  I see on the developer's blog he's looking to get a better
config file format too.  The licensing issue clearly makes it the right choice
for Fedora.

Doug has the problem down; as an example, once upon a time I developed a network
appliance based on Redhat 9 with syslog-ng.  To the best of my knowledge there
are still several hundred of these around the world syslog-ng'ing back to the
central Fedora server.  rsyslog wasn't conceived of when I built it, and getting
all the machines updated is a task that would at least require development,
testing, and in this case regulatory approval.  rsyslog is pretty clearly the
right direction, it just couldn't be done inside of, say, 3 months.  Folks with
large server farms are likely to see similar issues.

I can't think of any precedent for the Fedora Project saying, "you can't run
this package anymore if you want updates," especially without notice.  It would
be capricious for us to do this to users when an alternative is available and
seemingly pretty straightforward.  I'm no proponent of mindless package count
expansion, but the alternative is just nasty.

I'm only concerned what will happen in F-9 and naturally the idea of having
three packages instead of one is not much attractive to me...  But I really
don't have a better solution, so I'll let the decision on the loggers maintainers.

Hi,

I believe there is a very simple solution for this problem - just force rsyslog
use the same pid file as sysklogd and syslog-ng. If rsyslog uses the same
pidfile we can still offer sysklog and syslog-ng RPMS without causing conflicts.

This is exactly the same solution that allowed us to have syslog-ng installed
side-by-side with sysklogd in the past (FC-3 .. FC-7) as both packages used
exactly the same log rotate file (same MD5 digest) in order to avoid the
logrotate problem.

Regards,
/jpo

References/notes:
[1] - syslog-ng specfile changelog: check the year 2005 entries 
[2] - check the May 2005 syslog-ng threads in the fedora-extras-list archives
      (http://www.redhat.com/archives/fedora-extras-list/2005-May/thread.html)
      In particular read the Jeremy Katz mails.
[3] - The syslog-ng pidfile is specified in its sysconfig file

Hi again,

While having the three logging daemons using the same the pid file
(/var/run/syslogd.pid) and shipping the same logrotate file would be best and
more versatile solution, you should be able to correct the conflict problem
doing the following:

  1)  change the pid file used by syslog-ng (use the same as rsyslog)

      File that needs to be modified:  /etc/sysconfig/syslog-ng

  2) replace the syslog-ng logrotate file by the rsyslog one
     
/jpo

Douglas,

There are new versions of eventlog and syslog-ng available:

http://www.balabit.com/downloads/files/syslog-ng/sources/2.0/src/eventlog-0.2.7.tar.gz

http://www.balabit.com/downloads/files/syslog-ng/sources/2.0/src/syslog-ng-2.0.9.tar.gz

jpo

jpo, thanks for the tips on how to make rsyslog, sysklogd, and syslog-ng not 
conflict.  I've been working on implementing your ideas for the past few days 
and should see an update come out here soon.

Douglas,

(In reply to comment #19)
> jpo, thanks for the tips on how to make rsyslog, sysklogd, and syslog-ng not 
> conflict.  I've been working on implementing your ideas for the past few days 
> and should see an update come out here soon.

I still think the problem should be solved by having rsyslog use
/var/run/syslogd.pid as its pid file (the rsyslog package broke the existent
status quo).

During the rsyslog review Peter "believed" that the logrotate problem had been
solved (see bug #243831 comments 20 and 26).   Apparently at the time that new
logrotate feature wasn't tested (otherwise the review would/should have been
blocked).

jpo