On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: > >Given all the talk about not being able to influence upstream, it > >occurred to me to actually take a look at which of the major > >applications I rely on actually come with native systemd service > >scripts. I just went through the documentation, and in some cases, > >the source trees, for the following: > >bind9 > >apache > >sympa > >mailman > >mysql > >mariadb > >postgres > >postfix > >spamassassin > >amavisd > >clamav > > > >Most come with sysvinit scripts, several come with their own > >startup scripts (e.g., apachectl) that get dropped into rc.local. > >Not a one comes with a native systemd service file (even though, > >when you search through the mysql documentation it tells you that > >oracle linux has switched to systemd). > >So... with systemd, one has to: > >- rely on packagers to generate systemd service files, and/or, > >- rely on systemd's support for sysvinit scripts, which > > > >In the later case, one just has to read: > >http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > >to get very, very scared > > > >Among the implications of this, the old standby of installing > >software from upstream (bypassing packaging), has just gotten a > >lot riskier. > > Interesting, since I posted this, a bunch of people have jumped on > my comment that relying on packagers and systemd to support sysvinit > scripts seems increasingly risky, but... > > Not a single person has commented on the observation that upstream > developers, at least of core server applications, are thoroughly > ignoring systemd.
No one commented because that's false. I also guess that you will use anyone response to later justify "see, it try to force its way by forcing people to integrate with systemd". Either way, that's gonna be used as a way to criticize. > So tell me again about all the great features > that are in such demand, that systemd is a solution for? Most of the features do not requires anything upstream. For example : - being able to autorestart when crashed. Done on the distribution side, and usually, that's a policy left to the admin, not upstream - limiting the service with cgroups. Again, dependent on the installation, so left to the admin. - limiting the access with namespaces. Again, depend on the setup, so left for the admin. - starting on demand, that can be achieved with either xinetd protocol ( ie, reading stdin, writing stdout instead of a socket ), so no need here. - clean environment, that's not a feature that requires any patch upstream - journald integration, again, most software do use syslog, so no special need to have something that work. There is a few feature that requires any upstream patches. 1) socket activation using the systemd way ( ie, not xinetd ) 2) using journald to have more metadata that regular syslog 3) notifcation protocol and automated restart > Where's > the demand? Maybe upstream knows something that seems to elude > systemd proponents? Apache has support as a module in trunk : https://httpd.apache.org/docs/trunk/mod/mod_systemd.html There is support for journal too, see mod_journal. And also see https://github.com/apache/httpd/commit/9e6638622be042eb00af5234a48049f7b5487a15#diff-92a02cae0d4feb2dfea5d1532ba1b977 for support directly in apache. HAProxy do have some support for integration https://github.com/jvehent/haproxy/blob/master/src/haproxy-systemd-wrapper.c Php-fpm does too : http://thanatos.be/2014/04/12/php-fpm-ondemand.html Nodejs has a module for nodejs application: https://savanne.be/articles/deploying-node-js-with-systemd/ Docker has support for it in various place ( socket activation, support in libcontainer ), and I could surely find lots of core stuff and newer code that do have native support. Dovecot have support for it, there is a service file : http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/dovecot.service.in There is support for it : http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/src/master/service-listen.c There is the upstream of mdadm who even wrote 2 articles on how to do it for nfs : http://lwn.net/Articles/584175/ http://lwn.net/Articles/584176/ Older software are just integrated with xinetd do not need anything. So for example, openssh already support socket activation like it does for xinetd. Had you done your homework and spent 5 minutes double checking your affirmation, you would surely have found the same links as me. just search for HAVE_SYSTEMD on github, bitbucket, etc. And to show there is demand, you can even look on modern configuration tools and you can see they all support to configure systemd : To give the 4 most spoken of at the moment : - ansible https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L396 - chef http://www.rubydoc.info/github/opscode/chef/Chef/Provider/Service/Systemd - puppet https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb - saltstack http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.systemd.html If no one wanted to use systemd on a server, they wouldn't have specific module for it. So instead of trying to find endless reasons to justify your position, please start to work on making sure sysvinit work as you want. Show the way of constructive contribution. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117223154.ge31...@gmail.com
