Project

General

Profile

Actions
Copy link

Bug #2377

closed

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

Added by Matthieu CERDA over 12 years ago. Updated over 12 years ago.

Status:
Released
Priority:
1 (highest)
Assignee:
Nicolas PERRON
Category:
System techniques
Target version:
2.4.0~alpha7
Pull Request:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

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
Actions
Copy link
 #1

Updated by Matthieu CERDA over 12 years ago

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

Applied in commit commit:8a97afd0bc1823998e08d452d2a8eb6b42ae813a

Actions
Copy link
 #2

Updated by Jonathan CLARKE over 12 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.

Actions
Copy link
 #3

Updated by Nicolas PERRON over 12 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 ?

Actions
Copy link
 #4

Updated by Matthieu CERDA over 12 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...

Actions
Copy link
 #5

Updated by Jonathan CLARKE over 12 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! :)

Actions
Copy link

Also available in: Atom PDF