14.8.0: ncm-cdispd restarted twice during Quattor upgrades

[jouvin]

It appears that ncm-cdispd is restarted twice during upgrades. This is harmless but unexpected. ncm-cdispd installation is responsible for one restart but the other one suggests that something else tries to restart ncm-cdispd. Would be good to identify the reason and either fix it or document it.

The isssue is open in this repo but the problem is likely to be in another component/repo.

[jouvin]

Culprit found: ccm.

[stdweird]

@jouvin care to explain what ccm did to cause the restart?

[jouvin]

It was a too quick message. ccm RPM as an install script that restart ncm-cdispd. In fact this is perfectly valid. With delayed processing of the ncm-cdispd, it should cause only one restart as all the restart action will take place during the same YUM transaction and that the real restart will happen at the end. The real problem is https://github.com/quattor/ncm-cdispd/issues/15, now understood. I close this issue which is a side effect rather than an issue...

[jouvin]

Late comment... behaviour understood and perfectly normal!

• ccm has to restart ncm-cdispd when it is upgraded to ensure that ncm-cdispd is using the last version of ccm and is able to access the profile in case the new version is required to read it (and if ncm-cdispd is not upgraded at the same time).That results in 2 attempts to restartncm-cdispdduring a Quattor client upgrade (the second one is the upgrade ofncm-cdispd` itself.
• The first attempt to restart ncm-cdispd send the signal to the existing process that continues to run until the completion of ncm-ncd but also start a second ncm-cdispd process that is blocked until the first ncm-ncd has completed (ncm-ncd lock). But the pid file now points to the second ncm-cdispd process. When the second attempt to restart ncm-cdispd occurs, it sends the signal to the second ncm-cdispd process with the consequence that there are 2 ncm-cdispd process during a Quattor upgrade. This is a correct behaviour and there is no reason to invent a complex solution to avoid that, IMO.

[stdweird]

some maybe we should remove ccm and ncm-cdispd (adn cdp-listend?) from the release process and only build new rpms when something actually changed?

[jouvin]

Why? This would be very confusing... Again, there is no problem in this double restart IMO (as long as configuration modules are properly written and don't restart services when there is no configuration changes).

[stdweird]

i agree it's confusing, and not harmful; but it's also unnecessary (and ncm-cdispd restart implies a ncm-ncd --co -all afaik). i was just wondering if it could be avoided.

[jouvin]

Personally, I'm in favour of sticking with the fact that one release contains everything... And we need:

• To restart ncm-cdispd if it was running when updating CCM to ensure that ncm-cdispd is using the most recent version and is able to access the profile.
• To restart ncm-dispd when upgrading it...

So it is probably better to leave with the 2 restarts of ncm-ncd that always existed in fact... just we realized it recently looking more carefully at the logs with the rewrite of ncm-cdispd.