I'm having problems with the init.d script. When starting it always fails: /etc/init.d/pymsn-t start * Starting MSN Jabber Transport ... [ !! ] According to /var/log/jabber/pymsn-t-debug.log it is actually started but after just 2 seconds it receives SIGTERM and stops again. I think the problem has to do with the python wrapper and I think the problem started when python was upgraded to 2.6. In the init.d script it says: start-stop-daemon .. ..something --exec /usr/bin/python /usr/lib64/python2.6/site-packages... something When starting at process with /usr/bin/python the process is actuaully called /usr/bin/python2.6 (can be seen with ps). That seem to be a problem. If I modify the init.d script to say /usr/bin/python2.6 instead it works fine. I'm just not sure that's a very nice solution. On the other hand... if python is upgraded in the future pymsn-t has to be recompiled anyway. One odd thing though. If i run the start-stop-daemon command by hand exactly as it is in the init.d script it starts up fine and start-stop-daemon even returns 0 (true). I have noticed that the packages net-im/pyaim-t and net-im/pyicq-t use a similar script so they might have the same problem (I don't use them and haven't tested them). Maybe even more python applications in portage with init scripts have this problem now.
Created attachment 205104 [details, diff] Insert python version in initscript Could this be a solution to the problem? Inserts the current python version in the init-script when installing.
I experience a similar problem with denyhosts. executing /etc/init.d/denyhosts start fails and /etc/init.d/denyhosts status yields "not running". But denyhosts is running because I receive emails about new hosts added to hosts.deny. I think this has something to do with bug 286424. denyhosts is a python script and I find a process named 'python2.6' running in top. I observe this behavior on my amd64 box as well as on my sparc box. Both use python-2.6 as python interpreter. If necessary, I can post emerge --info of both boxes as well. Please let me. BR, Dustin
This is in no way special to pymsn and imho a major issue.
CCing dev-portage, as this got introduced for portage/python3-stuff (see -dev post).
IMO haubi already gave a possible solution to this this on -dev ML. But really I think this wrapper should have been much more developed and tested in an overlay/development environment. See also previous bug on this wrapper.
Having the wrapper hijack argv[0] seems somewhat unfriendly. If some people prefer that behavior, you could make it configurable with an environment variable and they can just drop a file in /etc/env.d to control it.
dev-python/virtualenv doesn't work when argv[0] isn't changed (see bug #280959).
(In reply to comment #4) > CCing dev-portage, as this got introduced for portage/python3-stuff (see -dev > post). It wasn't introduced for portage/python3 stuff, but to allow to easily (without patching many packages which use hardcoded 'python' or '/usr/bin/python' path) support installation of Python modules (which don't use distutils/setuptools/distribute) for multiple Python versions (e.g. 2.5, 2.6).
*** Bug 281704 has been marked as a duplicate of this bug. ***
I somehow can't reproduce this bug. What version of sys-apps/baselayout and sys-apps/openrc do you use?
(In reply to comment #10) > I somehow can't reproduce this bug. What version of sys-apps/baselayout and > sys-apps/openrc do you use? > sys-apps/baselayout: 1.12.12
Can anybody with =sys-apps/baselayout-2* and =sys-apps/openrc-0.5* reproduce this bug?
(In reply to comment #12) > Can anybody with =sys-apps/baselayout-2* and =sys-apps/openrc-0.5* reproduce > this bug? > Long as baselayout-1 is in stable, it needs to work with it as well.
(In reply to comment #13) > Long as baselayout-1 is in stable, it needs to work with it as well. We only try to find in which circumstances this bug occurs. Apparently now I cannot reproduce bug #280959, but I was able to reproduce it on 2009-08-22...
Openrc 0.5 seems to work fine.
Tested, seems it works on baselayout2/openrc-0.5. Is stabilization of them expected soon?
not in any time frame that would preclude fixing/working around in python-wrapper
(In reply to comment #12) > Can anybody with =sys-apps/baselayout-2* and =sys-apps/openrc-0.5* reproduce > this bug? I've got baselayout-2.0.1, openrc-0.5.2-r1 and encountering this bug with wicd-1.6.2.
It seems that the reason python-wrapper doesn't work with start-stop-daemon is that 'pidof -x' (used by start-stop-daemon) does not work with python-wrapper. Even if I don't know why this happens here and how to fix it, this is what I've seen so far (tried with http-replicator): *) "pidof -x http-replicator" seems to do something like: $ grep http-replicator /proc/*/stat *) When /usr/bin/http-replicator uses '#!/usr/bin/python2.6', the resulting /proc/<pid>/stat contains "<pid> (http-replicator) ...", and 'pidof -x' *does* find http-replicator running. *) When /usr/bin/http-replicator uses '#!/usr/bin/python', and this is the python-wrapper *with* updating argv[0], the resulting /proc/<pid>/stat contains "<pid> (python2.6) ...", and 'pidof -x' does *not* find http-replicator running. *) When /usr/bin/http-replicator uses '#!/usr/bin/python', and this is a python-wrapper *without* updating argv[0], the resulting /proc/<pid>/stat contains "<pid> (python2.6) ..." and 'pidof -x' does *not* find http-replicator running. Whatever python-wrapper does with argv[0], it seems irrelevant to pidof. /proc/<pid>/stat seems to contain the first arg of execv*(), whatever argv[] is passed later. So the problem with start-stop-daemon and python-wrapper seems to be that python-wrapper does one more execv*(). Uh oh, so many "seem's" :/
Could be of interest: This is pidof from sys-apps/sysvinit-2.86-r10 on amd64.
(In reply to comment #19) Maybe python-wrapper could update argv[0] with the name of the script, which uses '#!/usr/bin/python', so that /proc/<pid>/stat contain e.g. "<pid> (http-replicator) ...". Could you check, if it would work?
Well, it isn't too easy to find out what is the script: I've tried execv*(EPYTHON, &argv[1]), but this breaks with shebangs like "#!/usr/bin/python -O" as well as immediate usage like: python -c 'import sys'. It does even break simple scripts, as python's main() expects itself to be in argv[0], even when strace doesn't show this. OTOH, http-replicator doesn't work when using "#! /usr/bin/env python2.6" either, so maybe this cannot be fixed within python-wrapper at all...
When I first ran into this problem I wrote a wrapper shell script but had to run it by hand. I switched my default python back to 2.5 and all was well until 2.5 went away and I was left with 2.6 and a broken http-replicator.
Created attachment 213083 [details] Prevent python-wrapper from segfaulting Don't know if it helps also for You, but here is patch for app-admin/eselect-python-20090824 that prevents it from segfaulting (improper if() check on NULL pointer). Probably if python-wrapper will not segfault, it may solve some of python related problems.
(In reply to comment #24) It's not related to this bug, I will include it.
(In reply to comment #25) > (In reply to comment #24) > > It's not related to this bug, I will include it. s/I/but I/
*** Bug 286278 has been marked as a duplicate of this bug. ***
*** Bug 287559 has been marked as a duplicate of this bug. ***
Created attachment 213125 [details, diff] python-wrapper-fix_argv0.patch People still able to reproduce this bug: Please test this patch. (This patch fixes problem with `pidof -x` and maybe fixes problem with start-stop-daemon.)
With the patch applied to python-wrapper pymsn-t starts successfully. ps outputs the following: /usr/lib64/python2.6/site-packages/pymsn-t/pymsn-t.py /usr/lib64/python2.6/site-packages/pymsn-t/pymsn-t.py -b -c /etc/jabber/pymsn-t.xml -l /var/log/jabber/pymsn-t.log With the original python-wrapper but with the init.d script modified to use /usr/bin/python2.6 it said: /usr/bin/python2.6 /usr/lib64/python2.6/site-packages/pymsn-t/pymsn-t.py -b -c /etc/jabber/pymsn-t.xml -l /var/log/jabber/pymsn-t.log
(In reply to comment #29) > Created an attachment (id=213125) [details] > python-wrapper-fix_argv0.patch > > People still able to reproduce this bug: Please test this patch. Thanks, Arfrever. The patch solved the issue with denyhosts on both boxes. Service is recognized as running again.
(In reply to comment #30) > ps outputs the following: > > /usr/lib64/python2.6/site-packages/pymsn-t/pymsn-t.py > /usr/lib64/python2.6/site-packages/pymsn-t/pymsn-t.py -b -c > /etc/jabber/pymsn-t.xml -l /var/log/jabber/pymsn-t.log > > With the original python-wrapper but with the init.d script modified to use > /usr/bin/python2.6 it said: > > /usr/bin/python2.6 /usr/lib64/python2.6/site-packages/pymsn-t/pymsn-t.py -b > -c /etc/jabber/pymsn-t.xml -l /var/log/jabber/pymsn-t.log Apparently this problem seems to not occur, when start-stop-daemon is called with new wrapper scripts, which have been suggested in [1]. [1] http://archives.gentoo.org/gentoo-dev/msg_0eb0a982108b8c108980c4c7eb6facbf.xml
People able to reproduce this bug: Please synchronize the tree and (re)install app-admin/denyhosts. Next test `/etc/init.d/denyhosts restart` with both unmodified python-wrapper (from app-admin/eselect-python-20090824) and with python-wrapper with patch from comment #29 applied.
(In reply to comment #33) > People able to reproduce this bug: Please synchronize the tree and (re)install > app-admin/denyhosts. Next test `/etc/init.d/denyhosts restart` with both > unmodified python-wrapper (from app-admin/eselect-python-20090824) and with > python-wrapper with patch from comment #29 applied. Sorry, but with this modified version of denyhosts, it does not work again with both patched and unpatched eselect-python. The daemon is running but is not recognized as running: * Starting DenyHosts daemon... [ !! ]
(In reply to comment #34) Which version of baselayout / openrc do you use? Does adding option '--interpreted' to call to start-stop-daemon in /etc/init.d/denyhosts change anything? start-stop-daemon --interpreted --name denyhosts.py --start --exec /usr/bin/denyhosts.py -- --daemon -c /etc/denyhosts.conf
(In reply to comment #35) (Also test without '--name denyhosts.py')
patch from comment #29 has fixed my problems with http-replicator
(In reply to comment #35) > Which version of baselayout / openrc do you use? I am on stable amd64, so it's baselayout-1.12.13 and no openrc. > Does adding option '--interpreted' to call to start-stop-daemon in > /etc/init.d/denyhosts change anything? No, that option does not exist in baselayout-1. I get: # start-stop-daemon: unrecognized option '--interpreted' (In reply to comment #36) > (Also test without '--name denyhosts.py') No success with that either. Same failure as with the modified /etc/init.d/denyhosts script. The service is running but no recognized as such.
(In reply to comment #38) Sorry for the bug spam. Forgot to add that this is for patched as well as for unpatched eselect-python-20090824.
(In reply to comment #34) Could you check in gdb what causes this problem? gdb --args start-stop-daemon --name abcd --start --exec /usr/bin/denyhosts.py -- --daemon -c /etc/denyhosts.conf
(In reply to comment #40) > Could you check in gdb what causes this problem? > > gdb --args start-stop-daemon --name abcd --start --exec /usr/bin/denyhosts.py > -- --daemon -c /etc/denyhosts.conf Here is some information in more detail: legolas dustin # /etc/init.d/denyhosts status * status: stopped legolas dustin # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... DenyHosts could not obtain lock (pid: 8496) [Errno 17] File exists: '/var/run/denyhosts.pid' legolas dustin # ps aux | grep 8496 root 8496 0.2 0.3 91824 13668 ? S 09:01 0:02 /usr/bin/python2.6 /usr/bin/denyhosts.py-2.6 --daemon -c /etc/denyhosts.conf legolas dustin # kill 8496 legolas dustin # gdb --args start-stop-daemon --name abcd --start --exec /usr/bin/denyhosts.py -- --daemon -c /etc/denyhosts.conf warning: Can not parse XML syscalls information; XML support was disabled at compile time. GNU gdb (Gentoo 7.0 p1) 7.0 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /sbin/start-stop-daemon...(no debugging symbols found)...done. (gdb) run Starting program: /sbin/start-stop-daemon --name abcd --start --exec /usr/bin/denyhosts.py -- --daemon -c /etc/denyhosts.conf Executing new program: /bin/env Executing new program: /usr/bin/python-wrapper Executing new program: /usr/bin/python2.6 [Thread debugging using libthread_db enabled] Executing new program: /usr/bin/python2.6 [Thread debugging using libthread_db enabled] Program exited normally. (gdb)
(In reply to comment #41) What is shown by `/etc/init.d/denyhosts start` when the following line is in /etc/init.d/denyhosts? start-stop-daemon --verbose --name denyhosts.py --start --exec /usr/bin/denyhosts.py -- --daemon -c /etc/denyhosts.conf
(In reply to comment #42) > (In reply to comment #41) > > What is shown by `/etc/init.d/denyhosts start` when the following line is in > /etc/init.d/denyhosts? > > start-stop-daemon --verbose --name denyhosts.py --start --exec > /usr/bin/denyhosts.py -- --daemon -c /etc/denyhosts.conf legolas dustin # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... Starting /usr/bin/denyhosts.py... [ !! ]
Created attachment 220639 [details, diff] Patch for python-wrapper Please test the new set of patches. Apply this patch to app-admin/eselect-python. Apply the next patch to dev-lang/python:2.6.
Created attachment 220641 [details, diff] Patch for dev-lang/python:2.6
(In reply to comment #44) > Please test the new set of patches. > Apply this patch to app-admin/eselect-python. > Apply the next patch to dev-lang/python:2.6. I've tested with those two patches, but the issue is not solved. This is the output when starting denyhosts (I upgraded to baselayout-2 in the meantime): # /etc/init.d/denyhosts restart * Starting DenyHosts daemon ... * Detaching to start `/usr/bin/denyhosts.py' ... DenyHosts could not obtain lock (pid: 2732) [Errno 17] File exists: '/var/run/denyhosts.pid' * start-stop-daemon: failed to start `/usr/bin/denyhosts.py' [ !! ] * ERROR: denyhosts failed to start # kill $(cat /var/run/denyhosts.pid ) # /etc/init.d/denyhosts restart * Starting DenyHosts daemon ... * Detaching to start `/usr/bin/denyhosts.py' ... * start-stop-daemon: /usr/bin/denyhosts.py died [ !! ] * ERROR: denyhosts failed to start Portage 2.1.7.16 (default/linux/amd64/10.0, gcc-4.3.4, glibc-2.10.1-r1, 2.6.31-gentoo-r6-stable x86_64) ================================================================= System uname: Linux-2.6.31-gentoo-r6-stable-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T8100_@_2.10GHz-with-gentoo-2.0.1 Timestamp of tree: Mon, 22 Feb 2010 07:45:01 +0000 app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.10 dev-lang/python: 2.6.4 dev-python/pycrypto: 2.1.0_beta1 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.0-r1 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc: 4.3.4 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA dlj-1.1 PUEL cadsoft skype-eula" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe -msse4.1" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/bin/mygenkernel /usr/sbin/run-crons /usr/share/X11/xkb /usr/share/cairo-dock/plug-ins/wifi/wifi /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=core2 -O2 -pipe -msse4.1" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages multilib-strict news parallel-fetch protect-owned sandbox sfperms strict test unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://de-mirror.org/distro/gentoo/ ftp://mirror.netcologne.de/gentoo/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo" LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,relro -Wl,-z,now" LINGUAS="en de" MAKEOPTS="-j5" PKGDIR="/home/ftp/binpkg/" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="--timeout=500" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/g-ctan /usr/local/portage/modified /usr/local/portage/own /usr/local/portage/layman/alon-barlev /usr/local/portage/layman/sping /usr/local/portage/layman/science /usr/local/portage/layman/desktop-effects /usr/local/portage/layman/sunrise" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X X509 Xaw3d a52 aac aalib accessibility acl acpi alsa amd64 amr amrnb amrr amrwb apm async audacious audiofile bash-completion battery berkdb bindist bl bluetooth branding bzip2 cairo cardbus cdaudio cdda cdinstall cjk cli consolekit cracklib crypt css ctype cups curl cxx dbus devil dga directfb dri dts dv dvd dvdr eds encode evo exchange exif fam fame fbcon fbcondecor fbsplash ffmpeg flac fontforge foomaticdb fortran ftp gd gdbm gif gimp git glade glitz gmp gphoto2 gs gsm gstreamer gtk gtkhtml guile hal hddtemp hdf5 iconv icq icu idn ieee1394 imagemagick imap imlib iproute2 jack java javascript jpeg jpeg2k kerberos keyscrub kino kpathsea lame lapack laptop latex lcms libcaca libnotify libsamplerate libsexy libv4l2 libwww live lm_sensors logrotate loop-aes lzma lzo mad memlimit mikmod mime mjpeg mmx mmxext mng modules mono motif mp2 mp3 mp4 mpeg mplayer mudflap multilib musepack ncurses nls nntp nowin nptl nptlonly nsplugin ntp nuv nvidia ogg opengl openmp opensslcrypt pam pch pcmcia pcre pda pdf perl plotutils png posix ppds pppd print python qt3support quicktime readline reflection rtsp ruby rubytests samba sasl schroedinger sdl server session simplexml slang sndfile soap sockets sou speex spell spl sse sse2 sse3 sse4.1 ssl ssse3 startup-notification stream subversion svg swat sysfs syslog tcpd tga theora threads tiff truetype unicode usb userlocales v4l v4l2 vcd vdpau vim-syntax vim-with-x vorbis wifi winbind wma wmf wxwindows x264 xanim xcomposite xfce xinetd xls xml xmp xorg xpm xsl xulrunner xv xvid xvmc zlib" ALSA_CARDS="hda-intel mpu401" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="fuji ptp2" ELIBC="glibc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS_FLAGS
(In reply to comment #46) After starting denyhosts, what is the output of these commands?: pidof -x denyhosts.py killall denyhosts.py
(In reply to comment #47) > After starting denyhosts, what is the output of these commands?: > pidof -x denyhosts.py > killall denyhosts.py # pidof -x denyhosts.py # killall denyhosts.py # In other words, nothing...
This happens also with twisted-based init scripts. I had no idea why this was happening on my dev and production machines until I found this bug by random chance, just because I read some very insightful rant about a certain way of breaking things: http://blog.flameeyes.eu/2010/02/22/what-s-wrong-with-gentoo-anyway Diego is right.
I just noticed that after upgrade to app-admin/eselect-python-20091230 (without patch from comment 29) my problem with http-replicator returned. I tried with patches from comment 44 and comment 45. But it doesn't helped.
(In reply to comment #48) > (In reply to comment #47) > > After starting denyhosts, what is the output of these commands?: > > pidof -x denyhosts.py > > killall denyhosts.py > > # pidof -x denyhosts.py > # killall denyhosts.py > # > > In other words, nothing... The output of `killall` is actually correct. I noticed that I had tested previous patch without Python wrapper script (and `pidof -x` was working correctly). `pidof -x` checks if argv[1] matches process name, while `killall` checks only process name.
Created attachment 221107 [details, diff] Patch for dev-lang/python:2.6 Please test the updated patch for dev-lang/python:2.6. (Changes in Python/sysmodule.c are not related to this bug.) Patch for python-wrapper remains unchanged. Please reinstall app-admin/denyhosts to ensure that some changes from python.eclass are applied. If the problem still exists, then post the output of these commands: /etc/init.d/denyhosts start ps aux | grep denyhosts | grep -v grep PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') cat /proc/${PID}/stat python -c "print(open('/proc/${PID}/cmdline').read().split('\x00'))" pidof -x denyhosts.py killall denyhosts.py
(In reply to comment #52) > Created an attachment (id=221107) [details] > Patch for dev-lang/python:2.6 > > Please test the updated patch for dev-lang/python:2.6. > (Changes in Python/sysmodule.c are not related to this bug.) > > Patch for python-wrapper remains unchanged. > > Please reinstall app-admin/denyhosts to ensure that some changes from > python.eclass are applied. I replaced python-2.6-PYTHON_PROCESS_NAME.patch by python-2.6-process_data.patch and did #emerge -1 python eselect-python denyhosts Killing the running denyhosts process by hand and then restarting it yields: # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... * Detaching to start `/usr/bin/denyhosts.py' ... * start-stop-daemon: /usr/bin/denyhosts.py died [ !! ] * ERROR: denyhosts failed to start > If the problem still exists, then post the output of these commands: > /etc/init.d/denyhosts start # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... * Detaching to start `/usr/bin/denyhosts.py' ... * start-stop-daemon: /usr/bin/denyhosts.py died [ !! ] * ERROR: denyhosts failed to start > ps aux | grep denyhosts | grep -v grep # ps aux | grep denyhosts | grep -v grep root 3175 0.4 0.2 88720 11960 ? S 13:59 0:00 /usr/bin/python2.6 /usr/bin/denyhosts.py --daemon -c /etc/denyhosts.conf > PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') (obviously no output) > cat /proc/${PID}/stat # cat /proc/${PID}/stat 3175 (denyhosts.py) S 1 3174 3174 0 -1 4202560 2167 0 0 0 33 1 0 0 20 0 1 0 1422016 90849280 3016 18446744073709551615 4194304 4197060 140735626622112 18446744073709551615 140403984862131 0 0 16781313 16898 18446744071579855225 0 0 17 0 0 0 0 0 0 > python -c "print(open('/proc/${PID}/cmdline').read().split('\x00'))" # python -c "print(open('/proc/${PID}/cmdline').read().split('\x00'))" ['/usr/bin/python2.6', '/usr/bin/denyhosts.py', '', '', '', '', '--daemon', '-c', '/etc/denyhosts.conf', ''] > pidof -x denyhosts.py # pidof -x denyhosts.py 3175 > killall denyhosts.py (no output)
sys-apps/openrc maintainers: Could you explain start-stop-daemon's behavior? The content of /proc/${PID}/stat shows that process name is now correct (i.e. "denyhosts.py") and the content of /proc/${PID}/cmdline shows that argv[1] is correct.
(In reply to comment #54) > sys-apps/openrc maintainers: > Could you explain start-stop-daemon's behavior? start-stop-daemon(8) describes it quite well. > The content of /proc/${PID}/stat shows that process name is now correct (i.e. > "denyhosts.py") and the content of /proc/${PID}/cmdline shows that argv[1] is > correct. > uberpc roy # ps ax | grep deny 10817 ? S 0:00 /usr/bin/python2.6 /usr/bin/denyhosts.py-2.6 --daemon -c /etc/denyhosts.conf uberpc roy # cat /proc/10817/cmdline /usr/bin/python2.6/usr/bin/denyhosts.py-2.6--daemon-c/etc/denyhosts.conf Obviously the start-stop-daemon call in the init script won't work here. What's worse is that both the interpreter and the script are version branded, so I don't see how you can easily fix this how you would like to. Quite often, the simplest approach is the best. pidfiles! start() { ebegin "Starting DenyHosts daemon" start-stop-daemon --start --exec /usr/bin/denyhosts.py \ --pidfile /var/run/denyhosts.pid \ -- --daemon -c /etc/denyhosts.conf eend $? } There. denyhosts works again.
(In reply to comment #55) > Quite often, the simplest approach is the best. pidfiles! > > start() { > ebegin "Starting DenyHosts daemon" > start-stop-daemon --start --exec /usr/bin/denyhosts.py \ > --pidfile /var/run/denyhosts.pid \ > -- --daemon -c /etc/denyhosts.conf > eend $? > } > > There. denyhosts works again. Confirmed. Thanks Roy!!
(In reply to comment #55) > uberpc roy # ps ax | grep deny > 10817 ? S 0:00 /usr/bin/python2.6 /usr/bin/denyhosts.py-2.6 > --daemon -c /etc/denyhosts.conf > > uberpc roy # cat /proc/10817/cmdline > /usr/bin/python2.6/usr/bin/denyhosts.py-2.6--daemon-c/etc/denyhosts.conf > > Obviously the start-stop-daemon call in the init script won't work here. The attached patches cause that python removes "-2.6" from argv[1] (by overwriting it with '\0' characters) and calls prctl(PR_SET_NAME, process_name) to change process name to "denyhosts.py". These changes are sufficient for `pidof -x`, `killall` and `top`. Do you know, why they are insufficient for start-stop-daemon? Also do you know, why start-stop-daemon works on my system even when process name and argv[1] are wrong?
(In reply to comment #57) > The attached patches cause that python removes "-2.6" from argv[1] (by > overwriting it with '\0' characters) and calls prctl(PR_SET_NAME, process_name) > to change process name to "denyhosts.py". These changes are sufficient for > `pidof -x`, `killall` and `top`. Do you know, why they are insufficient for > start-stop-daemon? Because they match in different ways? pidof -x basically ignores argv[0] and tests against argv[1]. This means it will match `vim denyhosts.py-2.6` as well, which in my eyes is just wrong. I believe killall behaves in same way --name matching process name does exactly that In this case, the process name is /usr/bin/python2.6 (or maybe /usr/bin/python with your patches, I've not looked). > Also do you know, why start-stop-daemon works on my system even when process > name and argv[1] are wrong? I don't know what version of OpenRC/baselayout you're running.
(In reply to comment #58) > --name matching process name does exactly that > In this case, the process name is /usr/bin/python2.6 (or maybe > /usr/bin/python with your patches, I've not looked). The process name is "denyhosts.py" with my patches (or at least get_task_comm() in ${Linux_sources}/fs/proc/array.c returns "denyhosts.py"). > > Also do you know, why start-stop-daemon works on my system even when > > process name and argv[1] are wrong? > > I don't know what version of OpenRC/baselayout you're running. I use sys-apps/openrc-0.6.0-r1, sys-apps/baselayout-2.0.1 and Linux 2.6.32.
Created attachment 222473 [details, diff] Patch for sys-apps/openrc Please apply this patch to sys-apps/openrc and post the output of the following command with unmodified init script: /etc/init.d/denyhosts start
(In reply to comment #60) > Created an attachment (id=222473) [details] > Patch for sys-apps/openrc > > Please apply this patch to sys-apps/openrc and post the output of the following > command with unmodified init script: > /etc/init.d/denyhosts start > # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... spid: '20534' exec: '/usr/bin/denyhosts.py' argv[0]: '/usr/bin/denyhosts.py' argv[1]: '--daemon' argv[2]: '-c' pid: '20534' i: '0' WIFEXITED(i): '1' WEXITSTATUS(i): '0' [ ok ]
(In reply to comment #61) > Sorry, was not with the unmodified init script. Here with correct output: # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... spid: '29015' exec: '/usr/bin/denyhosts.py' argv[0]: 'denyhosts.py' argv[1]: '--daemon' argv[2]: '-c' pid: '29015' i: '0' WIFEXITED(i): '1' WEXITSTATUS(i): '0' * start-stop-daemon: /usr/bin/denyhosts.py died [ !! ] * ERROR: denyhosts failed to start
Please test (with unmodified init script) if previous patches (for python-wrapper and dev-lang/python:2.6) are sufficient when no wrapper script is involded: mv -f /usr/bin/denyhosts.py-2.6 /usr/bin/denyhosts.py /etc/init.d/denyhosts start
(In reply to comment #63) > involded s/involded/involved/
Created attachment 222883 [details, diff] Patch for app-admin/eselect-python After testing described in comment #63, please test the new set of patches.
Created attachment 222885 [details, diff] Patch for dev-lang/python:2.6
Created attachment 222887 [details, diff] Patch for python.eclass Please reinstall app-admin/denyhosts after applying this patch.
Created attachment 223211 [details, diff] Patch for dev-lang/python:2.6 The previous patches for dev-lang/python:2.6 and python.eclass had some bugs. Please test the new patches.
Created attachment 223213 [details, diff] Patch for python.eclass
Ensure that you use >=dev-lang/python-2.6.5-r1:2.6 and >=app-admin/eselect-python-20100321. Please wait about 1 hour, synchronize the tree, reinstall app-admin/denyhosts and post the output of: /etc/init.d/denyhosts start ps aux | grep denyhosts | grep -v grep PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') cat /proc/${PID}/stat python -c "print(repr(open('/proc/${PID}/cmdline').read()))" pidof -x denyhosts.py killall denyhosts.py
legolas dustin # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... [ ok ] legolas dustin # ps aux | grep denyhosts | grep -v grep root 28023 0.0 0.2 88016 11084 ? S 21:19 0:00 /usr/bin/python2.6 /usr/bin/denyhosts.py --daemon -c /etc/denyhosts.conf legolas dustin # PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') legolas dustin # cat /proc/${PID}/stat 28023 (denyhosts.py) S 1 28022 28022 0 -1 4202560 403 0 0 0 0 0 0 0 20 0 1 0 996997 90128384 2771 18446744073709551615 4194304 4197388 140734207653504 18446744073709551615 139723657674195 0 0 16781313 16898 18446744071579855617 0 0 17 0 0 0 0 0 0 legolas dustin # python -c "print(repr(open('/proc/${PID}/cmdline').read()))" '/usr/bin/python2.6\x00/usr/bin/denyhosts.py\x00--daemon\x00-c\x00/etc/denyhosts.conf\x00' legolas dustin # pidof -x denyhosts.py 28023 legolas dustin # killall denyhosts.py
Forgot to change to original init script... legolas dustin # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... * start-stop-daemon: /usr/bin/denyhosts.py died [ !! ] * ERROR: denyhosts failed to start legolas dustin # ps aux | grep denyhosts | grep -v grep root 28905 0.0 0.2 88012 11084 ? S 21:22 0:00 /usr/bin/python2.6 /usr/bin/denyhosts.py --daemon -c /etc/denyhosts.conf legolas dustin # PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') legolas dustin # cat /proc/${PID}/stat 28905 (denyhosts.py) S 1 28904 28904 0 -1 4202560 403 0 0 0 0 0 0 0 20 0 1 0 1015537 90124288 2771 18446744073709551615 4194304 4197388 140735365707168 18446744073709551615 140288117554643 0 0 16781313 16898 18446744071579855617 0 0 17 0 0 0 0 0 0 legolas dustin # python -c "print(repr(open('/proc/${PID}/cmdline').read()))" '/usr/bin/python2.6\x00/usr/bin/denyhosts.py\x00--daemon\x00-c\x00/etc/denyhosts.conf\x00' legolas dustin # pidof -x denyhosts.py 28905 legolas dustin # killall denyhosts.py
As mentioned in comment #63, could you run: mv -f /usr/bin/denyhosts.py-2.6 /usr/bin/denyhosts.py And post the output of: /etc/init.d/denyhosts start ps aux | grep denyhosts | grep -v grep PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') cat /proc/${PID}/stat python -c "print(repr(open('/proc/${PID}/cmdline').read()))" pidof -x denyhosts.py killall denyhosts.py
legolas dustin # mv -f /usr/bin/denyhosts.py-2.6 /usr/bin/denyhosts.py legolas dustin # /etc/init.d/denyhosts start * Starting DenyHosts daemon ... [ ok ] legolas dustin # ps aux | grep denyhosts | grep -v grep root 9083 0.0 0.1 82492 5532 ? S 22:26 0:00 /usr/bin/python2.6 /usr/bin/denyhosts.py --daemon -c /etc/denyhosts.conf legolas dustin # PID=$(ps aux | grep denyhosts | grep -v grep | awk '{print $2}') legolas dustin # cat /proc/${PID}/stat 9083 (denyhosts.py) S 1 9082 9082 0 -1 4202560 390 0 0 0 0 0 0 0 20 0 1 0 1399930 84471808 1383 18446744073709551615 4194304 4197388 140736253340896 18446744073709551615 139860484689363 0 0 16781313 16898 18446744071579855617 0 0 17 0 0 0 0 0 0 legolas dustin # python -c "print(repr(open('/proc/${PID}/cmdline').read()))" '/usr/bin/python2.6\x00/usr/bin/denyhosts.py\x00--daemon\x00-c\x00/etc/denyhosts.conf\x00' legolas dustin # pidof -x denyhosts.py 9083 legolas dustin # killall denyhosts.py legolas dustin #
*** Bug 293137 has been marked as a duplicate of this bug. ***
(In reply to comment #74) > legolas dustin # mv -f /usr/bin/denyhosts.py-2.6 /usr/bin/denyhosts.py > legolas dustin # /etc/init.d/denyhosts start > * Starting DenyHosts daemon ... > > [ ok ] It shows that the original problem (specific to python-wrapper) has been fixed. sys-apps/openrc maintainers: Why does it matter if given script (executed by start-stop-daemon) executes another script when process name (second field in /proc/${PID}/stat) and all members of argv (/proc/${PID}/cmdline) are the same?
I'm wondering if this would fix some of the issues I've had with python-based daemons in the past. Some of those still happen, IIRC. OpenRC guys?
does app-eselect/eselect-python from 2009-09 have any relevance to the python of today?
(In reply to Ian Delaney from comment #78) > does app-eselect/eselect-python from 2009-09 have any relevance to the > python of today? The code has not changed much. Please refrain from making comments if you have nothing to add.
No new info since 2010, and if it wasn't fixed before, 2016* almost-rewrite would certainly fix it or break it anew ;-).
