chkconfig doesn't always check for single instance services
Brought to you by:
brucewalker,
rogertsang
The default configuration should be "S initnode Y" The
only time that the "all" or "node=1,2,..." will fail is
if the "S" is specified in /etc/rc.d/ssiconfig. The
configuration should be determined (ssiconfig: in rc,
read from /etc/rc.d/ssiconfig, or default values), then
the checking done if "S" is the type. Right now the
type value is ignored except in the case in which it is
found in /etc/rc.d/ssiconfig.
Logged In: YES
user_id=297844
Per my description above an M type specified in "ssiconfig:"
line in RC script doesn't over-ride S type specified in
/etc/rc.d/ssiconfig.
Logged In: YES
user_id=945844
I have been looking at the chkconfig code. And I don't find
a check anywhere in the code where the incompatibility
between 'S' and 'all/node=x,y,..' is being verified.
The readSSIserviceInfo function does not do anything with
the value of type (S/M) read in either from
/etc/rc.d/ssiconfig or the individual rc-files. What should
it be doing with it anyway?
Further, at what point in the execution of chkconfig should
this incompatibility check be done and an error thrown?
Logged In: YES
user_id=297844
The function validateSSIServiceInfo() is the only one that I
found which looks at the S vs. M value and only from the
ssiconfig file. It set a variable "single_instance_svc"
which is later used to produce an error if an improper node
change is attempted. This needs to be fixed to perform as I
described. I don't think that validateSSIServiceInfo()
should be the point in which this value is read, it should
be read into the "struct service" structure just like the
other fields which behave as I described. Then the validate
code can just check that value from the single_instance field.
Logged In: YES
user_id=945844
A patch that extends current checks for compatibility
between S/M values and nodeclass has been checked in. This
introduces a new field 'instances' into struct service. This
value is updated in readSSIServiceInfo and verified in
validateSSIServiceInfo. Should fix the problem