-
Notifications
You must be signed in to change notification settings - Fork 80
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
cronie doesn't reexec itself causing pam errors #87
Comments
I do not think re-execing cronie is something I'd like to see in the code. This seems to me like a seriously ugly workaround for not properly restarting the crond on such a breaking pam update which should be a job of properly integrated distribution. |
BTW, such a breaking pam update should warrant full system restart as there might be also other long running processes (for example sshd and other login daemons) that are linked to libpam. And yes, the other option is to know about all long-running libpam users and restart all of them but that is quite hard to do. |
sshd reexecs. The only problematic program I encountered is cronie, especially it fails in a silent way (if you monitor only crond process existence and not weird cron log content). Distro has this mechanism but it is global and is disabled locally. I guess have to find a way to never disable it for crond. Or patch cronie locally to exit() if such pam error happens. |
With 17 years of being a rolling distro maintainer, I can confirm only crond has this problem. not just cronie, but other flavors too, because they probably have same codebase at some point, so share the design. |
Since more and more distributions are going into rolling distributions I'm rereporting this issue on github:
Or if cronie detects such errors it could die with critical error instead of silently (not) working (where silently is deamon exists but doesn't run its job and only logs errors due to permanently being in fatal state).
The text was updated successfully, but these errors were encountered: