starting ntlmaps from /etc/init.d/ntlmaps start returns ok. When I do ps auxw |grep ntlmals, returns nothing, no pid file exists either! when I use the command from the /etc/init.d/ntlmaps cd /var/log/ntlmaps && \ start-stop-daemon --quiet --start --background --exec /usr/bin/python \ --make-pidfile --pidfile ${PID_FILE} --chuid ntlmaps -- /usr/bin/ntlmaps < /dev/null && \ sleep 1 Reproducible: Always Steps to Reproduce: 1. /etc/init.d/ntlmaps start 2. ps auxw |grep ntlmaps returns nothing 3. run start-stop-daemon in shell as root works 100! Actual Results: ps auxw | grep ntlmals return nothing Expected Results: ntlmaps 16571 3.6 0.0 74968 8576 ? Ss 20:10 0:00 /usr/bin/python2.6 /usr/bin/ntlmaps The command line from the script start-stop-daemon works in shell as root 100% If I remove the --background switch from start-stop-daemon then it starts up but obviously doesn't go to the background and there for stuck the pid folder also does not exist if you emerge, I've set the folder up correctly with permissions. Why does --background work in bash shell and not in init script?
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
