I ran into a bug (which might be related to a previous bug from policyd-weight), at least in 2017Q3 branch that I am using. Namely it breaks the saltstack "enable" service due to the way it does the lookup and checks the name and compares to the rc script name.
I am not exactly which package is at fault here, as it might be more of a problem with salt and the logic is uses, than with policyd-weight.
The problem was with a state such as:
- name: policyd-weight
- enable: True
Salt is able to start this service, but it never modifies the rc.conf and it doesn't understand the convention used, thus it would fail a restart of the host/jail this state is applied to unless a salt highstate is run to correct the issue.
While I can work around this with salt by manually editing the rc.conf, I wonder if this bug needs to be revisited?
Apologies for the delay. I must have missed the original CC.
If I understand the problem here correctly, the Salt state you're applying fails to properly set the policyd_weight_enable="YES" in the rc.conf. It will *start* the service, but can't figure out how to _enable_ the same service.
The problem is that the service name and the sysrc name don't match.
service policyd-weight start
I just spent some time reproducing this. I have a fairly simple workaround:
- name: policyd-weight
- name: policyd_weight_enable
- value: "YES"
The Salt service module doesn't appear to support defining a service.running where the service name and the enable name don't match. In this case I suggest simply managing the service with the service state and the sysrc changes with the sysrc state.
If anything I think this is an upstream SaltStack bug that doesn't account for this edge-case.
(In reply to Christer Edwards from comment #2)
Oh no worries. Yes, I kinda came to the same conclusion you did about the cause; seemed like things were just a bit out of sync. I just don't know if it was upstream that is responsible for the BSD rc file, or what. Doesn't hurt to ask, right? :)
Thank you for the work around. I will file that away!
Is the workaround sufficient? Can we close this?
+1 to close.
(In reply to Danny McGrath from comment #6)
Closing this bug as per comments #5 and #6.
Whilst a workaround has been identified, I think that if FreeBSD allows the service name and the enable name to be different, then salt should be modified to support this. Suggest this could be submitted as a feature request to upstream?