With baselayout-2 and rc-status-0.3.0-r1, the rc-service lists the status of denyhosts as "crashed". However, the denyhosts process is running, it is not properly detected by rc-status. Reproducible: Always Steps to Reproduce: 1.rc-service denyhosts start 2.rc-status | grep denyhosts Actual Results: denyhosts [ crashed ] Expected Results: denyhosts [ ok ] rc-service will properly start, stop and restart the daemon.
I have the same versions of baselayout and openrc and I see the problem too. My version of denyhosts is 2.6-r1. The "crashed" status is also reported in response to `/etc/init.d/denyhosts status'.
I've got the same behavior on nfblockd (not in portage) when I send it SIGHUP with start-stop-daemon, so I guess this problem may be a bug in openrc. CC'ing base-system and Roy.
My problem seems to be unrelated so I'll report it later.
The denyhosts init script incorrectly uses the --name option. The process name would be python, or the full path to python. OpenRC-0.4.1 does not require the --name option at all as it can knows what the interpreter is if the file exists and can be read. And coldwind, please don't CC me unless you're sure it's an OpenRC bug. Gentoo should be big and clever enough to write init scripts or at least read the fine manual pages I wrote for start-stop-daemon.
Hello there! I have this problem too, openrc-0.4.1-r1. Does anybody has ability to test it on baselayout-1?
assigning to maintainer
Same error with baselayout 1.12.11.1 (and denyhosts 2.6-r1): fileserver ~ # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... [ !! ] fileserver ~ # /etc/init.d/denyhosts status * status: stopped fileserver ~ # ps -ef|grep deny root 13726 1 0 13:13 ? 00:00:00 /usr/bin/python2.6 /usr/bin/denyhosts --daemon -c /etc/denyhosts.conf Removing "--name denyhosts" from the init script (or using "--name python" instead) doesn't help either.
I confirm comment #7 and tested with --name python2.6 which seems to work for me.
--name denyhosts doesn't work anymore because of introducing python-wrapper, which execs selected python interpreter, so name gets overwriten by "python2.6". You can check that by changing denyhosts to denyhosts.py (/usr/bin/denyhosts.py has #!/usr/bin/python2.6 on the first line - it's probably a bug that this file gets installed at all, let alone with python version hard-coded) - it will work. Removing --name doesn't work, because then start-stop-daemon starts searching for /proc/*/exe pointing to denyhosts and of course won't find it. --name python2.6 on the other hand works for me on baselayout-1, but imho it's wrong - what if there is more than one python scripts running? So I added --pidfile option: start-stop-daemon --name python2.6 --pidfile /var/run/denyhosts.pid --start --exec /usr/bin/denyhosts -- --daemon -c /etc/denyhosts.conf Just --pidfile without --name doesn't work - start-stop-daemon checks exe then and fails.
Hmm, some more thoughts: It's bad to hard-code python version in init script, i think. We should use $(eselect python show). Also we can remove --name and change --exec to /usr/bin/$(eselect python show) (and move /usr/bin/denyhosts beyond -- of course), but this probably doesn't make much sense.
(In reply to comment #10) This bug discussion was helpful to me. I'm not much a Gentoo developer, but for what it's worth this variation on /etc/init.d/denyhosts worked for me: start() { ebegin "Starting DenyHosts daemon" start-stop-daemon --start -p /var/run/denyhosts.pid --exec /usr/bin/$(eselect python show) -- /usr/bin/denyhosts --daemon -c /etc/denyhosts.conf eend $? } Integrating this (i.e. a patch) into the main portage directory for DenyHosts would be great. (As said, being not a frequent contributor to Gentoo, I'm not sure what the right procedure is for that...)
(In reply to comment #11) > (In reply to comment #10) > > > This bug discussion was helpful to me. I'm not much a Gentoo developer, but for > what it's worth this variation on /etc/init.d/denyhosts worked for me: > > > start() { > ebegin "Starting DenyHosts daemon" > start-stop-daemon --start -p /var/run/denyhosts.pid --exec > /usr/bin/$(eselect python show) -- /usr/bin/denyhosts --daemon -c > /etc/denyhosts.conf > eend $? > } > > > Integrating this (i.e. a patch) into the main portage directory for DenyHosts > would be great. (As said, being not a frequent contributor to Gentoo, I'm not > sure what the right procedure is for that...) > i can confirm this solution works but it might not be the best one.
Created attachment 207903 [details, diff] Possible fix attached for the denyhosts initscript.
(In reply to comment #13) > Created an attachment (id=207903) [details] > fix for denyhosts init script > This possible fix would be cleaner than the one proposed in #11
(In reply to comment #9) > Just --pidfile without --name doesn't work - start-stop-daemon checks exe then > and fails. > So fix in comment #13 won't work, at least on baselayout-1
I'll repeat my suggestion: start-stop-daemon --name $(eselect python show) --pidfile /var/run/denyhosts.pid --start --exec /usr/bin/denyhosts -- --daemon -c /etc/denyhosts.conf
(In reply to comment #15) > (In reply to comment #9) > > Just --pidfile without --name doesn't work - start-stop-daemon checks exe then > > and fails. > > > So fix in comment #13 won't work, at least on baselayout-1 It does work with baselayout-2 (OpenRC), I didn't test it with baselayout-1 though.
(In reply to comment #16) > I'll repeat my suggestion: > start-stop-daemon --name $(eselect python show) --pidfile > /var/run/denyhosts.pid --start --exec /usr/bin/denyhosts -- --daemon -c > /etc/denyhosts.conf Before: denyhosts [ stopped ] After parafin suggestion: denyhosts [ started ]
The suggestion by parafin in comment #16 works fine for me. Any news on implementing this in the official version?
Can we please get an official fix in portage? I have quite a number of gentoo boxes with Denyhosts installed and I'd prefer not to have to manually patch all of the denyhosts init scripts (or deal with having to manually kill the process).
any news on this ?
(In reply to comment #16) > I'll repeat my suggestion: > start-stop-daemon --name $(eselect python show) --pidfile > /var/run/denyhosts.pid --start --exec /usr/bin/denyhosts -- --daemon -c > /etc/denyhosts.conf > This patch works like a charm with baselayout-1. My denyhosts executable is /usr/bin/denyhosts.py, instead of /usr/bin/denyhosts, though. I have denyhosts version 2.6-r1, baselayout-1.12.13, and python-2.6.4-r1 on an x86 machine. Please apply this simple patch ASAP. Like Chris, people do not want to patch everything manually.
Hi all, It looks like most of comments #7-22 are duplicates of bug 286424 Comment #4 is the real fix. IOW, patch from comment #13 should be correct. I'll try to get to the bottom of this.
IMHO, there is no fix that would work on baselayout-1 with both 20091230 and 20100321 eselect-python versions. Probably with stabilization of eselect-python-20100321 this bug will go away altogether. Smb should run some tests.
(In reply to comment #24) > Probably with stabilization of eselect-python-20100321 this bug will go away > altogether. Smb should run some You mean like bug 316367 ? :)
For stable hosts (baselayout-1, not openrc): You need python-2.6.5-r2, not an upgraded eselect-python. Relevant packages: [binary R ] app-admin/eselect-python-20091230 [binary R ] sys-apps/baselayout-1.12.13 USE="unicode -bootstrap -build -static" [binary R ] dev-lang/python-2.6.5-r2 USE="berkdb gdbm ipv6 ncurses readline ssl threads (wide-unicode) xml -build -doc -examples -sqlite -tk -wininst" [binary R ] app-admin/denyhosts-2.6-r1 For ~arch hosts (baselayout-2, openrc): (Tested with stable python-2.6.4-r1). I couldn't reproduce the issue. Relevant packages: [binary R ] app-admin/eselect-python-20091230 [binary R ] dev-lang/python-2.6.4-r1 USE="berkdb gdbm ncurses readline ssl threads (wide-unicode) xml -build -doc -examples -ipv6 -sqlite -tk -wininst" [binary R ] sys-apps/baselayout-2.0.1 USE="-build" [binary R ] sys-apps/openrc-0.6.1-r1 USE="ncurses pam unicode -debug" [binary R ] app-admin/denyhosts-2.6-r1 So, it looks like this problem will resolve itself without package changes. Does anyone disagree? Comments welcome.
Haven't checked, but comments to bug 315919 seem to indicate that comment #26 is probably true.
I'm running on a stable system, denyhosts always had rc-status "crashed". Just upgraded to dev-lang/python-2.6.5-r2, and the problem disappears. Thanks Jeremy for the writeup. Cheers, Nico
on amd64 (app-admin/denyhosts-2.6.1-r1) with python-2.6.5-r2 and eselect-python-20100321 the problem is gone :)
Works for me too! At last my bootup sequence looks healthy with green OKs all along. Portage 2.1.8.3 (default/linux/amd64/10.0/desktop, gcc-4.4.3, glibc-2.10.1-r1, 2.6.32-gentoo-r7 x86_64) ================================================================= System uname: Linux-2.6.32-gentoo-r7-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T7500_@_2.20GHz-with-gentoo-1.12.13 Timestamp of tree: Sat, 29 May 2010 08:30:18 +0000 app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.5-r99, 3.1.2-r3 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6, 1.7.9-r1, 1.8.5-r3, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 3.4.6-r2, 4.3.4, 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.33 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA dlj-1.1 skype-eula" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu"
It do _not_ work for me, even with python-2.6.5-r2. Portage 2.2_rc67 (default/linux/amd64/10.0, gcc-4.4.3, glibc-2.10.1-r1, 2.6.33-vs2.3.0.36.30.4-gentoo x86_64) ================================================================= System uname: Linux-2.6.33-vs2.3.0.36.30.4-gentoo-x86_64-Intel-R-_Xeon-TM-_CPU_2.80GHz-with-gentoo-1.12.13 Timestamp of tree: Tue, 01 Jun 2010 22:15:01 +0000 app-shells/bash: 4.0_p37 dev-lang/python: 2.6.5-r2, 3.1.2-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.65 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu"
I'm also still having this problem. Tried updating it with noconfmem and reselecting python version, but with no result. Portage 2.2_rc67 (default/linux/x86/10.0/desktop, gcc-4.4.3, glibc-2.11.1-r0, 2.6.27-openvz-briullov.1-r2-srv i686) ================================================================= System uname: Linux-2.6.27-openvz-briullov.1-r2-srv-i686-Intel-R-_Atom-TM-_CPU_330_@_1.60GHz-with-gentoo-2.0.1 Timestamp of tree: Thu, 03 Jun 2010 23:00:23 +0000 distcc 3.1 i686-pc-linux-gnu [enabled] ccache version 2.4 [enabled] app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.5.4-r2, 2.6.5-r2, 3.1.2-r3 dev-python/pycrypto: 2.1.0 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.3.3-r2, 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.7b virtual/os-headers: 2.6.33
@Valdimir and Alexander: please try if it works when you apply the patch attached to this bug: http://bugs.gentoo.org/attachment.cgi?id=207903
(In reply to comment #33) > @Valdimir and Alexander: please try if it works when you apply the patch > attached to this bug: http://bugs.gentoo.org/attachment.cgi?id=207903 Yes, with that patch it works.
The patch doesn't even apply to current installed files. I question the results.
Created attachment 249674 [details, diff] Possible fix attached for the denyhosts initscript. Looks like they've changed the filename of the denyhosts file without bumping the version of the package. Patch is updated, please try again.
I confirm this patch works after re-emerging the unbumped denyhosts. Can we please get it in the tree? The blocker is effectively resolved (except for sparc-fbsd and x86-fbsd).
I've just tested my patch with baselayout-1 and it works, just like with baselayout-2.
(In reply to comment #37) > I confirm this patch works after re-emerging the unbumped denyhosts. Can we > please get it in the tree? The blocker is effectively resolved (except for > sparc-fbsd and x86-fbsd). > If someone can explain why some people have issues and some don't, that would be nice (like I tried with comment #26). No issues here for bl-1 or bl-2 hosts with version in the tree.
(In reply to comment #39) > (In reply to comment #37) > > I confirm this patch works after re-emerging the unbumped denyhosts. Can we > > please get it in the tree? The blocker is effectively resolved (except for > > sparc-fbsd and x86-fbsd). > > > > If someone can explain why some people have issues and some don't, that would > be nice (like I tried with comment #26). No issues here for bl-1 or bl-2 hosts > with version in the tree. > The bug is only for baselayout-2 (as noted in the description), the patch fixes it and doesn't break baselayout-1. The Python thingy was a different problem I guess. And aside from that, the way the current init script works is kinda weird anyway, the process creates a pid file, why not use it?
Ok, thanks for the explanation. I didn't get that there were multiple issues here (or something). You have your patch from comment #36 committed. +*denyhosts-2.6-r4 (07 Oct 2010) + + 07 Oct 2010; Jeremy Olexa <darkside@gentoo.org> -denyhosts-2.6-r3.ebuild, + +denyhosts-2.6-r4.ebuild, files/denyhosts.init: + Modify init script (in place) to fix bug 244700 affecting baselayout-2 + users. Revision bump to force the new file install. Work by Lex Brugman
