BusyBox Bug and Patch Tracking
BusyBox
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001330 [BusyBox] Other major always 05-01-07 13:23 05-02-07 15:02
Reporter edh View Status public  
Assigned To BusyBox
Priority normal Resolution won't fix  
Status closed   Product Version 1.2.x
Summary 0001330: start-stop-daemon with --make-pidfile and --pidfile on httpd applet creates the wrong pid# in pidfile
Description When start-stop-daemon is starting the httpd applet, and told to make a pidfile, it does so, but creates a pidfile containing the pid of the original process not the running one. httpd probably starts and forks, letting the parent die. There should be an option to httpd to prevent this so you can use pidfiles for it created by start-stop-daemon.
Additional Information
Attached Files

- Relationships

- Notes
(0002337)
edh
05-02-07 13:53

This is also the case when using start-stop-daemon to start telnetd. So I guess it applies to all servers that fork immediately and detach. I needed the pid for httpd, and now need it for telnetd.

There is a work around in some cases. You can use start-stop-daemon to send signals, like SIGHUP to servers, removing the need for pidfiles generally.
 
(0002338)
vda
05-02-07 15:02

Auto-daemonizing programs fork children, then parent dies. ssd have no way detecting this.

Most of daemons have an option to suppress daemonization:

# telnetd --help
        -F Stay in foreground
        -i Run as inetd subservice

# httpd --help
        -f Do not daemonize

Use this if you start them from ssd.
 

- Issue History
Date Modified Username Field Change
05-01-07 13:23 edh New Issue
05-01-07 13:23 edh Status new => assigned
05-01-07 13:23 edh Assigned To  => BusyBox
05-01-07 13:23 edh Issue Monitored: edh
05-02-07 13:53 edh Note Added: 0002337
05-02-07 15:02 vda Note Added: 0002338
05-02-07 15:02 vda Status assigned => closed
05-02-07 15:02 vda Resolution open => won't fix


Copyright © 2000 - 2006 Mantis Group
Powered by Mantis Bugtracker