Description of problem: Let's have a service "myservice" and its unit file contains: [Service] Type=simple PIDFile=/var/run/myservice2.pid ExecStart=/bin/myservice1 Content of /bin/myservice1: #!/bin/bash /bin/myservice2 Content of /bin/myservice2: #!/bin/bash echo $$ > /var/run/myservice2.pid sleep 1000 rm /var/run/myservice2.pid So after starting the pids and ppids look like: pid ppid name 100 1 myservice1 101 100 myservice2 systemd starts the service right, but Main PID is always set to 100, no matter what is in /var/run/myservice2.pid Version-Release number of selected component (if applicable): systemd-26-8.fc15 How reproducible: every-time Steps to Reproduce: 1. create a service unit file + scripts like in $description 2. systemctl daemon-reload 3. systemctl start myservice.service 4. cat /var/run/myservice2.pid 5. systemctl status myservice.service and compare Main PID with the previous step Actual results: systemd doesn't respect PIDFile= Expected results: systemd does respect PIDFile= even when Type!=forking Additional info: It seems to me like this bug preserve correct socket activation handling in bug #714426 and maybe has some other consequences.
Using PIDFile with Type=simple looks like a contradiction. From man systemd.service: If set to simple (the default value) it is expected that the process configured with ExecStart= is the main process of the service. Do you really need to set PIDFile? Why?
(In reply to comment #1) > Do you really need to set PIDFile? Why? Because the use case in comment #0. I know, it is not how daemon usually works, but mysqld works similar currently and it would be hard (maybe unacceptable for upstream) to change it (mysqld_safe runs mysqld and re-run it if mysqld fails + do much more stuff). I'm not sure if PIDFile for simple service will help, but if I use the same process (mysqld) directly, it works like a charm.
I suspect the problem with the socket is caused by something else, though I have not looked closely yet.
Well, it doesn't make sense to set PIDFile= by simple services, you're right. The right approach is to use forking (if the first process ends after fork()). But let's look at the following use case: If the first process spawns another and wait for him, the main process PID is set wrong in systemd. Nevertheless, we can use a "notify" type and send a MAINPID= message to systemd using sd_notify() function, which works well. Then if we want to use a socket activation, systemd passes a main_pid in LISTEN_PID variable, which doesn't work if we specify the main process by PIDFile or notify message explicitly (systemd sends pid of the first process always). This preserves services that use type "forking" or "notify" to use a socket activation. I'm not sure if it is intentional, but I think it could be possible to use a socket activation by types "forking" or "notify" (with more active processes). Or is it not? Note: changing the title
Hmm, so you don't want systemd to wait for anything when spawning a service, but the process systemd starts is actually not the main process of the service? We currently don't support that, but we probably could fix that. I'll add this to the TODO list.
(In reply to comment #5) > Hmm, so you don't want systemd to wait for anything when spawning a service, > but the process systemd starts is actually not the main process of the service? Yes, but I thought this had been already implemented by notify message with text "MAINPID=xxx". Shouldn't this one do the same thing?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
On the todo list http://cgit.freedesktop.org/systemd/systemd/plain/TODO
Given that we will be only back porting important fixes for F15 at this point in time I'm moving this RFE against Rawhide so it does not get forgotten or lost in the EOL process.
Similar issue has been discussed at [1], where a pid file would be watched and a service would be considered started only after a pid has been written there. [1] http://lists.freedesktop.org/archives/systemd-devel/2012-June/005668.html
https://github.com/systemd/systemd/blob/master/TODO#L740-L741