Rudder

Applied in commit commit:8a97afd0bc1823998e08d452d2a8eb6b42ae813a

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.

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 ?

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...

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! :)