-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CFE-3982: Random process killing #5362
Conversation
The `cfengine3.service` has `Wants` on all our services which ensures they are started when the `cfengine3.service` starts. If an individual service is enabled with `systemctl enable`, it should only be added to the respective systemd target in which it should start.
@cf-bottom jenkins, please |
a329134
to
26eb4af
Compare
26eb4af
to
a04d5ba
Compare
Sure, I triggered a build: Jenkins: https://ci.cfengine.com/job/pr-pipeline/10028/ Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-10028/ |
@vpodzime We have systemd units mirrored in Masterfiles: cfengine/masterfiles#2760 |
Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just some smaller comments, thanks for working on this 🚀
WantedBy=cfengine3.service was removed from systemd service templates for individual components. It was un-necessary as cfengine3.service already wants the individual services. cfengine/core#5362 Ticket: CFE-3982 Changelog: commit
Instead of requiring that the file name ends with e.g. "cf_lock.lmdb", just check if the file name contains the string. This ensures that files like `cf_lock.lmdb.backup` match as well. And if someone renames their `cf_lastseen.lmdb` to `cf_lock.lmdb_cf_lastseen.lmdb` or something similar, it's not our fault they get wrong output.
This function totally doesn't do what its name says. It only checks if the DB was modified in the current boot and if not, it restores it from the latest backup. Which is done and the end of every agent run. So this function effectively reverts the locks DB to the state of the last agent run on every boot dropping significant data like daemon locks. Ticket: CFE-3982 Changelog: cf_lock.lmdb is no longer restored from backup on every boot
It's no longer being used in locks.c, but it can potentially be useful for being called explicitly. After all, it's a complementary function to BackupLockDatabase() which is also non-static. Ticket: CFE-3982 Changelog: None
If a non CFEngine process has a matching PID and start time, we shouldn't try to kill it because it's practically impossible that it is a real holder of one of our locks in cf_lock.lmdb. Most likely it's an unfortunate process that ended up with the matching PID and start time after a reboot. Ticket: CFE-3982 Changelog: Only CFEngine processes are now killed as expired lock owners Co-authored-by: Benoît Peccatte <[email protected]>
a04d5ba
to
6234c8c
Compare
@cf-bottom jenkins, please |
Sure, I triggered a build: Jenkins: https://ci.cfengine.com/job/pr-pipeline/10033/ Packages: http://buildcache.cfengine.com/packages/testing-pr/jenkins-pr-pipeline-10033/ |
WantedBy=cfengine3.service was removed from systemd service templates for individual components. It was un-necessary as cfengine3.service already wants the individual services. cfengine/core#5362 Ticket: CFE-3982 Changelog: commit (cherry picked from commit 4e490e7)
WantedBy=cfengine3.service was removed from systemd service templates for individual components. It was un-necessary as cfengine3.service already wants the individual services. cfengine/core#5362 Ticket: CFE-3982 Changelog: commit (cherry picked from commit 4e490e7)
Merge together:
#5362
cfengine/buildscripts#1332
cfengine/masterfiles#2760