I'm skipping to the questions I can answer. On Sat, May 18, 2013 at 2:44 PM, Michael Scherer <[email protected]> wrote: > - we should avoid as much as possible to use Type=forking when we can > avoid it. > > This one is likely the one that will be met with resistance from > packagers, so before adding it as warning, I would like to be sure that > I am not totally wrong. > > A standard daemon will fork ( likely twice ) in the background, do > various stuff and then write the pidfile on /run. > > By not going in the background, we can : > - avoid forking 1 or 2 times for nothing, > - avoid taking memory for /run, and avoid taking a inode > > So that's should be a little bit better in most case, or do I miss > anything ? > ( ie, something like "this is so negligible that we shouldn't care" )
That's not correct. Doing Type=simple services is generally undesirable because they lack proper support for dependent units only starting after startup completes (versus when startup begins, which is all systemd knows about a Type=simple unit). Type=notify is the most desirable because it gives the benefits you list for Type=simple but still allows proper dependency effects. However, Type=notify requires use of systemd APIs from the daemon's own code. If a service is socket-activiated, though, dependencies on the service itself are generally unnecessary, as units can depend on the socket instead. In such situations, Type=simple is quite good, with Type=notify offering almost only academic advantages over Type=simple. > - if using Type=forking, it is better to use PIDFile, > While systemd seems to support fine to guess the main pid, I think this > should be avoided when possible , according to > http://lists.freedesktop.org/archives/systemd-devel/2011-June/002690.html . > So does it make sense to send a warning if there is a service that do > not use PIDFile and of type Forking ? Absolutely. While the guessing behavior is solid, any packager should be able to set this explicitly. > - some package install directly file in /usr/lib/systemd/system/*.wants > There is some special case ( like plymouth ), but usually, that > shouldn't be done directly in the package, but better done in %post, and > in /etc ? No, the systemd ideal is that packages should not ever install systemd units or settings into /etc. Lennart's long-term goal is for daemons to not install anything by default to /etc, but I think our scope of authority in this discussion ends with systemd-related matters. > IE, is this right to make a warning or a error when that occurs ? It should be an error. > I was also interested into checking the syntax of systemd file, but > since systemd is moving quite fast, I doubt to be able to keep a up to > date parser of unit/service/timer/snapshot files. And duplicating code > of systemd in python do not seems like a smart move. It should be possible to invoke something in systemd to sanity-check the included unit files. Is it okay if the Python invokes a subprocess? If not, I work to add unit file sanity checking to the C APIs and extend our Python bindings. > I didn't found any way to reuse systemd code, but I think that a tool > like desktop-file-validate would be quite useful for all distributions. Agreed. -- David Strauss | [email protected] | +1 512 577 5827 [mobile] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
