-
Notifications
You must be signed in to change notification settings - Fork 149
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
register DAEMON and EVENTS processes so cyr_info proc can list them #4522
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
elliefm
force-pushed
the
v39/proc-info-for-daemons
branch
5 times, most recently
from
June 9, 2023 05:49
0c77f97
to
979f751
Compare
elliefm
force-pushed
the
v39/proc-info-for-daemons
branch
2 times, most recently
from
June 21, 2023 00:53
5dbe167
to
bb04488
Compare
will be needed for master to use its functions
(this just makes the next commit easier to read)
elliefm
force-pushed
the
v39/proc-info-for-daemons
branch
5 times, most recently
from
June 23, 2023 03:53
9f99dfd
to
9ccabd2
Compare
and existing callers now check the return value and fatal themselves
The defining property of these objects is that they are listening on a port, which conflicts with Cyrus's use of DAEMON for things that are not listening on a port.
not strictly related to this PR, but I've been wanting to do this for ages, and now I can, and it shows that the previous commit works
elliefm
force-pushed
the
v39/proc-info-for-daemons
branch
from
June 26, 2023 05:28
9ccabd2
to
6ba241f
Compare
elliefm
changed the title
V39/proc info for daemons
register DAEMON and EVENTS processes so cyr_info proc can list them
Jun 26, 2023
ksmurchison
approved these changes
Jun 26, 2023
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.
LGTM
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
reviewers: This will be easiest to review commit-by-commit.
cyr_info proc
lists all the running processes for cyrus.conf SERVICES entries. This PR extends this to also include processes for EVENTS and DAEMON entries. With this change,cyr_info proc
lists all* running processes managed bymaster
.The existing SERVICES processes register themselves using the API functions provided by imap/proc.c. EVENT and DAEMON processes are expected to often be external scripts, so their registration is taken care of directly by master. This required relocating the proc.c API functions from libcyrus_imap to libcyrus_min (so that master can call them), and refactoring to make them re-entrant (because master needs to register its many children, not itself).
Some Cassandane internals needed a small refactor to make this testable, and I found and fixed a bug in our cunit test logging too.
Processes from the START section are not registered, and thus not listed by
cyr_info proc
. Since these are by definition short-lived processes that only run once during startup -- and if they fail, startup fails -- it didn't seem worth it. I could be persuaded otherwise.