Preventing "cf-serverd" from running
76 views
Skip to first unread message
t.d...@servicemusic.org.uk
Feb 12, 2021, 2:05:05 PM2/12/21
to help-cfengine
Systems: RHEL7/8 (systemd); CFE-community 3.10 (migrating to 3.12); tests on 3.12
A normal RHEL installation has an umbrella "cfengine3" service which starts three daemons: "cf-execd", "cf-monitord" and "cf-serverd". On most of our systems we don't need "cf-serverd" (nor, at present, "cf-monitord").
How can we prevent those from starting? (Ultimately this prevention will itself be configured from local policy, but that's a later step.)
Even with "systemctl disable cf-serverd" (and confirmed that "systemctl status cf-serverd" reports "disabled") that process still starts.
This problem came to light when I tried, as a first attempt, to disable it with:
- ...usebundle => standard_services("cf-serverd", "disable")
but it still restarted. So to debug it directly, I tried those direct "systemctl..." commands.
- How, at the direct "systemctl" level, might we truly disable "cf-serverd"?
- How might we then code that in local policy?
Surely we're not the first people here.
Have a good weekend.
-- David Lee
Aleksey Tsalolikhin
Feb 12, 2021, 11:40:08 PM2/12/21
to t.d...@servicemusic.org.uk, help-cfengine
Hi David,
By default the core components are expected to be running in all cases.
It's the update policy (entrypoint: update.cf) that ensures they are running.
Check out:
and
and
cf-serverd is not just for serving files, you know -- it also listens for connections from cf-runagent, which you can use to trigger additional runs of cf-agent (with extra classes defined if needed). This can be useful for triggering special (unscheduled) runs of CFEngine, for example to trigger a state transition (as for a scheduled deployment).
I've been down this road myself once -- I said, oh, we're not really using cf-monitord, I'll turn it off and save some CPU cycles and memory - and it broke some of the inventory promises in the policy framework (I don't remember what just now, but it's one of those built in inventory things, like disk size I think it was, or disk free or something) -- but maybe you're not using that.
Yep, it's disk_free:
[:/var/cfengine/masterfiles] 2 $ grep -r mon\.|grep -i disk
grep: cf_promises_release_id: Permission denied
grep: cf_promises_validated: Permission denied
inventory/any.cf: string => "$(mon.value_diskfree)",
inventory/any.cf: if => isvariable( "mon.value_diskfree" );
[:/var/cfengine/masterfiles] $
grep: cf_promises_release_id: Permission denied
grep: cf_promises_validated: Permission denied
inventory/any.cf: string => "$(mon.value_diskfree)",
inventory/any.cf: if => isvariable( "mon.value_diskfree" );
[:/var/cfengine/masterfiles] $
So, I turned cf-monitord back on, because it's super useful to see which hosts are approaching 100% disk full. (We were aggregating inventory information in a centrally searchable place.)
You'd be departing from the standard configuration -- I don't advise it unless you have some strong security or resource limitation type reasons. :)
But, if you want to stop CFEngine from ensuring cf-serverd and cf-monitord are running, check out that file... Notice it says "do not edit" on it, so test your changes well!
I don't recommend it. :)
Best,
Aleksey
--
Founder
Vertical Sysadmin, Inc.
Achieve real learning.
--
You received this message because you are subscribed to the Google Groups "help-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/40d0751b-c7ae-4297-8aa6-5f8465941789n%40googlegroups.com.
Aleksey Tsalolikhin
Feb 12, 2021, 11:51:59 PM2/12/21
to t.d...@servicemusic.org.uk, help-cfengine
P.S. As a further note, making this change will complicate upgrades -- since it's not configurable in the MPF which core components will be running, you'll have to carry your patch across from MPF version to MPF version when you upgrade. :)
--
Founder
Vertical Sysadmin, Inc.
Achieve real learning.
t.d...@servicemusic.org.uk
Feb 17, 2021, 5:38:31 AM2/17/21
to help-cfengine
Aleksey: Many thanks for your replies. Most helpful!
This attempted disabling of cf-serverd and cf-monitord is something ancient (before my time) in our config. In doing our RHEL8 work, I spotted that it wasn't working, and had probably never worked since the introduction of RHEL7/systemd. So I had been heading down the road of repairing it in our config. But your replies indicate that we should, at a more fundamental level, question why we are trying to disable them at all. Good question. I had considered the question a little and backed off; you encourage me to consider it further and push forward! I'll reframe the issue with colleagues to propose that we simply remove this ancient legacy stuff.
Thanks again.
-- David Lee
-- Diamond Light Source, UK
Nick Anderson
Feb 17, 2021, 12:43:07 PM2/17/21
to t.d...@servicemusic.org.uk, help-cfengine
As Aleksey noted, there is an assumption that cf-serverd and cf-monitord are running. No, they aren't strictly required, but they shouldn't be eating a bunch of resources either.
cf-serverd is used for sharing files, handling requests from cf-runagent, and in the Enterprise version, it's what cf-hub talks to in order to get reports about the current state and promise outcomes back to the hub.
cf-monitord measures things providing variables related to those measurements (last measured value, average value, standard deviation of value) and also defines classes related to those measurements indicating if the measured vale is 1, 2, or 3 standard deviations higher or lower than the average, e.g.
[root@hub]# cf-agent --show-evaluated-classes | grep -i mon cf_serverd_VmRSS_low monitoring,source=environment,hardclass cfengine_in_low monitoring,source=environment,hardclass cpu0_low monitoring,source=environment,hardclass cpu1_low monitoring,source=environment,hardclass cpu_low monitoring,source=environment,hardclass diskfree_low monitoring,source=environment,hardclass entropy_misc_in_low monitoring,source=environment,hardclass entropy_misc_out_low monitoring,source=environment,hardclass entropy_postgresql_in_high monitoring,source=environment,hardclass entropy_postgresql_out_low monitoring,source=environment,hardclass entropy_www_alt_out_low monitoring,source=environment,hardclass entropy_www_out_low monitoring,source=environment,hardclass entropy_wwws_in_low monitoring,source=environment,hardclass entropy_wwws_out_low monitoring,source=environment,hardclass io_readdata_low monitoring,source=environment,hardclass io_reads_low monitoring,source=environment,hardclass io_writes_low monitoring,source=environment,hardclass io_writtendata_normal monitoring,source=environment,hardclass loadavg_low monitoring,source=environment,hardclass mem_cached_low_normal monitoring,source=environment,hardclass mem_free_low_normal monitoring,source=environment,hardclass mem_total_high monitoring,source=environment,hardclass messages_normal_anomaly monitoring,source=environment,hardclass,source=persistent messages_normal_dev1 monitoring,source=environment,hardclass messages_normal_dev2 monitoring,source=environment,hardclass,source=persistent otherprocs_low monitoring,source=environment,hardclass postgres_in_high monitoring,source=environment,hardclass rootprocs_low monitoring,source=environment,hardclass smtp_in_low monitoring,source=environment,hardclass ssh_in_low monitoring,source=environment,hardclass ssh_out_low monitoring,source=environment,hardclass unexpected_local_user_count_high monitoring,source=environment,hardclass users_low monitoring,source=environment,hardclass www_alt_out_low monitoring,source=environment,hardclass www_in_low monitoring,source=environment,hardclass www_out_low monitoring,source=environment,hardclass wwws_in_low monitoring,source=environment,hardclass wwws_out_low monitoring,source=environment,hardclass
If you still want to disable things, there are some docs on Configuring component management in the MPF, did you try the things listed there?
- …usebundle => standard_services("cf-serverd", "disable")
but it still restarted. So to debug it directly, I tried those direct "systemctl…" commands.
Might be worth trying to "mask" the cf-serverd unit: usebundle => standard_services("cf-serverd", "mask")
Not sure if that would do it or not.
For 3.17 systemd related service policy was extracted into it's own bundle (but still works via standard_services).
t.d...@servicemusic.org.uk
Feb 18, 2021, 9:00:08 AM2/18/21
to help-cfengine
Thanks, Nick. That's useful.
As I noted in my subsequent response to Aleksey, this attempted disabling seems to be historical legacy. And as you both note, attempting this is unusual (especially nowadays) and possibly counter-productive.
Given that our attempt has been failing since RHLE7 (systemd), and is questionable in principle, it sounds like the best course of action is simply to abandon the attempted disabling and "go with the flow", letting the daemons run naturally. (For other reasons, I want to leave our tiny, and dwindling, residue of RHEL6 untouched by any change). This is reinforced by a strong local wish (close to implementation) to pull our policy into line with MPF.
-- David Lee
Reply all
Reply to author
Forward
0 new messages