Le samedi 18 mai 2013 à 23:50 -0700, David Strauss a écrit : > I'm skipping to the questions I can answer. > > On Sat, May 18, 2013 at 2:44 PM, Michael Scherer <m...@zarb.org> 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.
In this case, that's Type=simple vs Type=forking. IE, is Type=forking better in term of having the startup being complete in the general case ? ( of course, there is always exception, but ). Type=notify is better, but that requires patching daemon. However, I could check if the binary is linked with libsystemd-daemon and trigger a warning for using Type=notify. > 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. Socket activated is another beast, and I do not know how I can check if a binary can be socket activated to trigger a warning. > > - 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. For /etc, yes, that's planned. But as said in the thread, my issue is : A package ship /usr/lib/systemd/system/foo.wants/bar.service as a link to /usr/lib/systemd/system/bar.service instead of using WantedBy=bar.service Is there one technical reason to prefer the former to the latter ? I would be tempted to mandate to use WantedBy because that would be more consistant with most packages, and hardcoding that setting on the FS forbid to override it in /etc, but maybe that's the goal. > > 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? It is ok. Bonus point for a parsable output, but just having a exit code would be ok for integration and let people run the binary and read errors. > If not, I work to add > unit file sanity checking to the C APIs and extend our Python > bindings. I think since lintian ( a similar tool for debian package ) is in perl, so having it in a external binary would be better for them. Now, from a deployment point of view, desktop-file-validate was backported on stable version for our builders at Mageia, and since the tool was self contained, that was ok, but pulling over a complete systemd backport on the server would likely be refused by any sysadmins, so if the tool could be compiled as a standalone without interfering with existing systemd installation, that would be nice. ( if not, I guess they can use some chroot tricks as i do for others quality checking tools ) -- Michael Scherer _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel