Bug #2377

On CentOS/RHEL 6, Rudder detects two running syslog daemons and, confused, outputs an error

Added by Matthieu CERDA over 2 years ago. Updated about 2 years ago.

Status:Released Start date:2012-03-15
Priority:1 Due date:
Assignee:Nicolas PERRON % Done:

100%

Category:Techniques - Sys & init promis
Target version:2.4.0~alpha7
Needs translating:No Pull Request:

Description

On CentOS/RHEL 6, Rudder detects two running syslog daemons and, confused, outputs an error.

In the promise, we match this:

  processes:
        "rsyslogd" 
                process_count => islaunched("rsyslogd");

        "syslog-ng" 
                process_count => islaunched("syslogng");

        "[^r]syslogd" 
                process_count => islaunched("syslogd");

BUT!

In EL6 systems, the running syslog is launched as:

/sbin/rsyslogd -i /var/run/syslogd.pid -c 4

Associated revisions

Revision 8a97afd0
Added by Matthieu CERDA over 2 years ago

Fixes #2377: The syslog daemon detection is now more robust on the common Technique

History

#1 Updated by Matthieu CERDA over 2 years ago

  • Status changed from New to Pending technical review
  • % Done changed from 0 to 100

Applied in commit commit:8a97afd0bc1823998e08d452d2a8eb6b42ae813a

#2 Updated by Jonathan CLARKE about 2 years ago

  • Status changed from Pending technical review to Discussion

I'm not convinced that this is a safer approach - consider a typical scenario where someone is using syslog and decides to upgrade to rsyslog. Then, most likely, both config files will exist... Causing this to fail.

Rather, why not just check the process using it's full path? Ie instead of "rsyslogd", use "/sbin/rsyslogd", etc. This would avoid the original problem.

#3 Updated by Nicolas PERRON about 2 years ago

  • Target version changed from 2.4.0~alpha7 to 2.4.0~beta1

I agree with Jon ! Just checking conf file is not sufficient and the full path seems better.

I increment to the next version as we have to tag 2.4.0~alpha7 soon but could you correct it quickly please ?

#4 Updated by Matthieu CERDA about 2 years ago

  • Assignee changed from Matthieu CERDA to Nicolas PERRON

Well, I do not agree: here is what you will get on a CentOS / RHEL 5 machine:

root      1695  0.0  0.3  10108   776 ?        Ss   Mar16   0:36 syslogd -m 0

Using a full path will not detect this syslog instance, which will cause Rudder to output errors that should not happen...

This is why I thought that the configuration file would be a safer approach.

I do not have any other idea than config file or full path...

#5 Updated by Jonathan CLARKE about 2 years ago

  • Status changed from Discussion to Released
  • Target version changed from 2.4.0~beta1 to 2.4.0~alpha7

Matthieu CERDA wrote:

Well, I do not agree: here is what you will get on a CentOS / RHEL 5 machine:

root 1695 0.0 0.3 10108 776 ? Ss Mar16 0:36 syslogd -m 0

Using a full path will not detect this syslog instance, which will cause Rudder to output errors that should not happen...

Ah, well this is different from the information you provided originally in the bug description, which was:

/sbin/rsyslogd -i /var/run/syslogd.pid -c 4

So we based our responses on the wrong information. Please be careful to explain in each and every ticket that you handle your reasoning and not just provide a result.

This is why I thought that the configuration file would be a safer approach.

Having looked at this again, I see that the aim of this promise is actually to edit the configuration file for syslog/syslog-ng/rsyslog. So, the logic currently implemented will actually edit all installed config files, which actually is a very safe approach: even if syslog and rsyslog (for example) are installed at the same, but only one is used, we will ensure that both config files are up to date.

This is OK for me, but would have been a lot easier to review provided 1) the correct information in the description, and 2) a summary of the reasoning followed in implementing this. Please help us save time collectively in the future! :)

Also available in: Atom PDF