[15898] in Kerberos-V5-bugs
[krbdev.mit.edu #8650] git commit
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Thu Mar 15 00:14:03 2018
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-8650@krbdev.mit.edu>
Message-ID: <rt-8650-48297.11.6576436309358@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #8650'":;
Date: Thu, 15 Mar 2018 00:13:49 -0400 (EDT)
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Exit with status 0 from kadmind
Typically, 0 denotes successful exit. In particular, init systems
will complain if another different value is returned. This presents a
problem for automated installation jobs which want to restart kadmind.
`service kadmin stop` typically sends SIGTERM, which is caught by
verto and passed to our handler. Besides cleanup, we then call
verto_break(), which causes the verto_run() event loop to return. The
weird return code has been present since the addition of the kadmin
code, which used a similar event model for signals.
https://github.com/krb5/krb5/commit/3e53f7b254c6704ad16942f98d9b222c9e069ef3
Author: Robbie Harwood <rharwood@redhat.com>
Committer: Greg Hudson <ghudson@mit.edu>
Commit: 3e53f7b254c6704ad16942f98d9b222c9e069ef3
Branch: master
src/kadmin/server/ovsec_kadmd.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
