Description of problem:
Let's have a service "myservice" and its unit file contains:
Content of /bin/myservice1:
Content of /bin/myservice2:
echo $$ > /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):
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
systemd doesn't respect PIDFile=
systemd does respect PIDFile= even when Type!=forking
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 , where a pid file would be watched and a service would be considered started only after a pid has been written there.