Closed jouvin closed 9 years ago
Culprit found: ccm
.
@jouvin care to explain what ccm did to cause the restart?
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...
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 restart
ncm-cdispdduring a Quattor client upgrade (the second one is the upgrade of
ncm-cdispd` itself.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.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?
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).
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.
Personally, I'm in favour of sticking with the fact that one release contains everything... And we need:
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.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
.
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 restartncm-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.