Skip to content
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

[3.18.x] CFE-3982: Random process killing #5368

Merged
merged 5 commits into from
Nov 8, 2023

Conversation

vpodzime
Copy link
Contributor

@vpodzime vpodzime commented Nov 8, 2023

No description provided.

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.

(cherry picked from commit 4e661a7)
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.

(cherry picked from commit 3e98366)
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
(cherry picked from commit db4eaf8)
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
(cherry picked from commit d824b88)
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]>
(cherry picked from commit 6234c8c)
@vpodzime vpodzime merged commit d229fb8 into cfengine:3.18.x Nov 8, 2023
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant