Bug 723942
Summary: | RFE: Allow Type=simple with PIDFile= | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Honza Horak <hhorak> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | harald, johannbg, johannbg, jsynacek, lpoetter, metherid, mschmidt, plautrba, rvokal |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-02-02 14:53:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 784611 |
Description
Honza Horak
2011-07-21 15:29:23 UTC
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 |