kadmind is not started correctly from the init script in /etc/init.d/heimdal-kadmind. The init script reports the service has started correctly, but it seems kadmind just quits silently. Reproducible: Always Steps to Reproduce: 1. emerge heimdal 2. configure heimdal (this is the tricky part :o) ) 3. /etc/init.d/heimdal-kadmind start 4. kadmin 5. list * (in kadmin prompt) Actual Results: I got an error saying that the connection was refused: commserver root # kadmin tgetent: warning: termcap entry too long kadmin> list * kadmin: connect(kerberos.example.com): Connection refused kadmin: failed to contact kerberos.example.com kadmin: kadm5_get_principals: Operation failed for unspecified reason kadmin> Expected Results: The command should have connected to the kadmind daemon and retrieved the list of Kerberos principals. Versions and use flags: commserver root # emerge -vp heimdal These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-crypt/heimdal-0.6.3-r1 +berkdb -ipv6 -krb4 +ldap +ssl 0 kB Emerge info: commserver root # emerge info Portage 2.0.50-r11 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.7) ================================================================= System uname: 2.6.7 i686 Pentium III (Katmai) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.caliu.info/pub/gentoo/ http://gentoo.mirror.sdv.fr" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="apache2 apm avi berkdb bitmap-fonts cjk crypt cups doc encode f77 foomaticdb gdbm gif gpm imap imlib java jpeg kerberos ldap libg++ libwww mad maildir mbox mikmod motif mpeg mysql ncurses nls oggvorbis opengl pam pdflib perl png postgres python quicktime readline samba sasl sdl slang snmp spell ssl svga tcpd tiff truetype x86 xml2 xmms xprint xv zlib" ------------------------------------------------------------------------------- I have done some tests, and the problem seems to be related to the --background switch in start-stop-daemon. If you run /usr/sbin/kadmind standalone, or using start-stop-daemon without the --background option, the daemon works as expected, but the process doen't go to the background. If you use the --background option, kadmind seems to exit without further notice (I have searched the logs without success)
start-stop-daemon --start --quiet --exec /usr/sbin/kadmind & seems to do the job... what's the difference between this and using --background?
I have also found this problem.
I have two bugs in kadmind : 1/ "kadmind" does not start "kadmind -d" gives "kadmind: socket af = 10: Address family not supported by protocol" The problem may be solved by changing a file lib/roken/mini_inetd.c. The line 137 : hints.ai_family = PF_UNSPEC; may be replaced by : #ifdef INET6 hints.ai_family = PF_UNSPEC; #else hints.ai_family = PF_INET; #endif 2/ kadmind seems to work only when started from xinetd or with "-d" parameter.
I have worked around this problem by running kadmind from xinetd using this service definition. The man page for start-stop says that using --background is a bad idea as any exit codes from the program it is starting cannot be caught and reported. service kerberos-adm { port = 749 socket_type = stream wait = no only_from = localhost .dingwall.me.uk user = root server = /usr/sbin/kadmind log_on_failure += USERID disable = no }
fixed in 0.6.4-r1 coming into portage in a few minutes.
*** Bug 85192 has been marked as a duplicate of this bug. ***
