Bug 723942 - RFE: Allow Type=simple with PIDFile=
RFE: Allow Type=simple with PIDFile=
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: systemd-RFE
  Show dependency treegraph
 
Reported: 2011-07-21 11:29 EDT by Honza Horak
Modified: 2016-02-02 09:53 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-02 09:53:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Honza Horak 2011-07-21 11:29:23 EDT
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.
Comment 1 Michal Schmidt 2011-07-21 11:39:35 EDT
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?
Comment 2 Honza Horak 2011-07-21 15:57:23 EDT
(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.
Comment 3 Michal Schmidt 2011-07-21 16:15:26 EDT
I suspect the problem with the socket is caused by something else, though I have not looked closely yet.
Comment 4 Honza Horak 2011-07-22 10:22:01 EDT
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
Comment 5 Lennart Poettering 2011-08-01 15:39:04 EDT
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.
Comment 6 Honza Horak 2011-08-02 03:03:39 EDT
(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?
Comment 7 Fedora Admin XMLRPC Client 2011-10-20 12:28:42 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Jóhann B. Guðmundsson 2012-01-25 08:50:15 EST
On the todo list http://cgit.freedesktop.org/systemd/systemd/plain/TODO
Comment 9 Jóhann B. Guðmundsson 2012-02-20 06:34:52 EST
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.
Comment 10 Honza Horak 2012-07-03 05:02:05 EDT
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

Note You need to log in before you can comment on or make changes to this bug.