CFE-3565/master: FreeBSD should enable/disable service using sysrc before trying to start/stop

[systemheld]

Service needs to be enabled in /etc/rc.conf before it can be started using service foobar start, otherwise service foobar onestart would be needed and service would not be started on system boot. Use sysrc to check rc.conf if service needs to be enabled and enable if needed.

[cf-bottom]

Thank you for submitting a PR! Maybe @nickanderson can review this?

[systemheld]

actually I'm not sure how to fix the ordering issue without duplicating stuff or introducing new classes to force the ordering as described in https://docs.cfengine.com/docs/3.12/guide-special-topics-modularity.html. Is there any obvious way to do this that I missed?

[gpiero]

Please, don't unconditionally enable services at boot.

I can think of at least a couple of reasons for not doing so:

1. you lose the ability to let the service status be managed by cfengine (I mean: starting and stopping it on demand at cfengine discretion and not necessarily at boot. i.e.: I only want to start a service at a defined time and only if the load average is below some threshold) NOTE: I've just discovered that standard_services unconditionally try to enable/disable services at boot (if I've read it correctly) but it simply doesn't succeed on my systems (Debian w/o systemd and FreeBSD). I still maintain that the correct behaviour is not trying to enable/disable the services at boot by default and that standard_services should be fixed. I think that services should be enabled/disabled at boot only explicitely via service_autostart_policy, but admittely I've not fully understood how services management works.

2. I, and I suppose others, prefer not to clog /etc/rc.conf and to use alternative files (/etc/rc.conf.d/service, /etc/rc.conf.d/service/*, /usr/local/etc/rc.conf.d/service, ...)

I would suggest to:

1. always use onestart/onestop/onerestart/... for starting/stopping/restarting/... the service (this would fix the base case)

What follows depends on an incomplete (or plain wrong) knowledge of how cfengine manages services

I think you could also: 2. extend/modify/add a service_method (e.g.: bootstart) for enabling the service.

but, note that imho in the ideal case you need 2 different service_methods:

1. the default one using /etc/rc.conf and $(service)_enable="YES"
2. one that receive the config file as a parameter (e.g.: /etc/rc.conf.d/$(service) ), and frankly I don't know if it's possible

Please also note that, at least, you need to canonify the $(service) name for getting the rcvar name. e.g.: the cf-execd service is enabled by the cf_execd_enable (note the hyphen being converted to underscore) rcvar. Given that services using not-derivable rcvars do not exists, otherwise you'd need a third service_method.

Moreover, you'd need a couple of corresponding methods with service_autostart_policy => "none" for setting the rcvar to "NO".

At this point however, I'm completely lost.

[nickanderson]

   **NOTE**: I've just discovered that standard_services unconditionally try to enable/disable services at boot (if I've read it correctly) but it simply doesn't succeed on my systems (Debian w/o systemd and FreeBSD). I still maintain that the correct behaviour is not trying to enable/disable the services at boot by default and that standard_services should be fixed. I _think_ that services should be enabled/disabled at boot only explicitely via service_autostart_policy, but admittely I've not fully understood how services management works.

I went digging at this a bit yesterday and I think that service_autostart_policy. It may be an orphan at this point.

Notable things:

• It does not appear to be used within the MPF except for in body service_method bootstart.
• I can't seem to find any useful examples of it's use on a non Windows system.
• service_policy, results in the definition of this.service_policy which is available inside the service_method body, but service_autostart_policy does not seem to do the same, so it can't be passed to the service_bundle as a variable

Comments:

I think this attribute is unfortunate. Since it's defined in the service_method body, we can't really set it dynamically based on service_policy because:

• No ability to leverage vars type promises within bodies
• Functions notably ifelse() can not be used to set the value of a body attribute directly, it generates an error that the function does not return the correct type.

To me, it seems that we need to stick to the service state having a specific meaning. E.g. service_policy => "running" means the service should be running, but that doesn't promise anything about starting at boot.

[nickanderson]

I circled back around to this and after re-reading the thread and changes I decided that we needed to separate the issue of not being able to manage a service state if the service was not enabled vs enabling a service to start on boot.

I agreed with @gpiero that we should not always enable services to start on boot and thought that it would be best to first address the issue of managing services on freebsd that were not enabled. So, I created CFE-4323 with an accompanying patch https://github.com/cfengine/masterfiles/pull/2834 that switches all of the sysvservice commands to be prefixed with one on freebsd.

@systemheld & @gpiero please feel free to check it out.

[nickanderson]

I am going to go ahead and close this one out since I think that the real issue around starting/stopping is resolved with https://github.com/cfengine/masterfiles/pull/2834 which uses one prefixed commands. If you want to continue on to chase the service enablement please pickup the discussion in CFE-3565.