Summary: | net-proxy/ntlmaps cannot fork to background | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Theunis <Theunis.Potgieter> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Theunis
2009-12-04 18:15:04 UTC
I spent some time investigating it and found the culprit - its 'is_daemon_running' function in initscript (from /lib/rcscripts/sh/rc-daemon.sh). Actually, ntlmaps starts fine, but then initcript tries to check if it started using 'is_daemon_running' function. It calls 'pidof /usr/bin/python' and checks if PID from pidfile is running. The problem is that 'pidof /usr/bin/python' returns empty list of PIDs and initscript assumes the daemon did not start and kills it. And 'pidof' returns no PIDs because of python-wrapper - actual process in this case is '/usr/bin/python2.6', not '/usr/bin/python' As a workaround, changing '/usr/bin/python' to '/usr/bin/python2.6' (substitute appropriate version of python for your system) in /etc/init.d/ntlmaps works. (In reply to comment #1) > I spent some time investigating it and found the culprit - its > 'is_daemon_running' function in initscript (from > /lib/rcscripts/sh/rc-daemon.sh). > Actually, ntlmaps starts fine, but then initcript tries to check if it started > using 'is_daemon_running' function. It calls 'pidof /usr/bin/python' and checks > if PID from pidfile is running. > The problem is that 'pidof /usr/bin/python' returns empty list of PIDs and > initscript assumes the daemon did not start and kills it. > > And 'pidof' returns no PIDs because of python-wrapper - actual process in this > case is '/usr/bin/python2.6', not '/usr/bin/python' > > As a workaround, changing '/usr/bin/python' to '/usr/bin/python2.6' (substitute > appropriate version of python for your system) in /etc/init.d/ntlmaps works. > Thanks, I will try your solution? Would there be a way for the system to return the current python binary and use that as a variable in the init script? Excuse the errors I make in spelling. quote: starting ntlmaps from /etc/init.d/ntlmaps start returns ok. When I do ps auxw |grep ntlmals, returns nothing, no pid file exists either! should actually be showing: starting ntlmaps from /etc/init.d/ntlmaps start returns ok. When I do ps auxw |grep ntlmaps, returns nothing, no pid file exists either! I tried the solution changing python to python2.6 (or python2) in the init.d script and it works. I don't know what the best approach would be by updating the init.d script by simply replacing python with python2.6 or updating the culprit rc-daemon.sh or updating python-wrapper. I guess the best approach would be to update the init.d script with a variable that could do what python-wrapper does... duplication? /usr/bin/python points to /usr/bin/python-wrapper where as /usr/bin/python2 points to /usr/bin/python2.6 I believe the proper solution would be changing /lib/rcscripts/sh/rc-daemon.sh script to account for python-wrapper's sneaky behavior - when python-wrapper apparently changes program name from what was supplied on a command line to whatever it wants. (this is not a regression over current stable) removed |