[opensuse-factory] low hanging fruit: packages with both init scripts and service files
Hi, Scanning through Factory logs I see that rpmlint found the following packages that have both a systemd service file as well as an init script. Since the latter is useless in Factory as it's shadowed by the service file the init script can be removed resp not installed: apache2 atheme autofs avahi clamav collectd courier-authlib courier-imap dbus-1-x11 dovecot21 erlang glusterfs gnugk gnump3d greenbone-security-assistant icecast keepalived laptop-mode-tools memcached netatalk nut openslp openvas-administrator openvas-manager openvas-scanner pcsc-lite php5 postfix postgrey pptpd proftpd pure-ftpd rabbitmq-server radvd rsync sanlock spamassassin squid subversion ufw ulogd util-linux varnish xl2tpd cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi,
Scanning through Factory logs I see that rpmlint found the following packages that have both a systemd service file as well as an init script. Since the latter is useless in Factory as it's shadowed by the service file the init script can be removed resp not installed:
I disagree. Don't remove the init script from the source to allow for it to be available for non-systemd build targets/products. Nope, not everything is systemd. Having both an init script and a service file does not harm. The interception nicely says that the call was redirected. See backwards compatibility ("rcpostfix restart") for management scripts. Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps. R. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Roman Drahtmueller <draht@suse.de> [04-09-14 12:28]:
Hi,
Scanning through Factory logs I see that rpmlint found the following packages that have both a systemd service file as well as an init script. Since the latter is useless in Factory as it's shadowed by the service file the init script can be removed resp not installed:
I disagree.
Don't remove the init script from the source to allow for it to be available for non-systemd build targets/products. Nope, not everything is systemd.
Having both an init script and a service file does not harm. The interception nicely says that the call was redirected. See backwards compatibility ("rcpostfix restart") for management scripts.
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
+1 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9 April 2014 18:28, Roman Drahtmueller <draht@suse.de> wrote:
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
I disagree - having both the systemd service file and the /etc/init.d file present on an installed machine causes confusion, both at a system level (eg. different answers to /etc/init.d/SuSEfirewall2 status and systemctl status SuSEfirewall) and at a sysadmin level ("What command do I use to do X?" - we don't want to have 2 different commands with 2 different results serving the same purpose) I agree with the argument that having the sysVinit script is good for non-systemd build targets, but for openSUSE 13.2 and beyond we use systemd, and in our distro, we should only be using systemd unit files Don't we have some nice macros that give us systemd unit files for some build targets and includes sysVinit files for others? if not..maybe that's an approach we can take. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 9 Apr 2014 22:53, Richard Brown <RBrownCCB@...> wrote:
On 9 April 2014 18:28, Roman Drahtmueller <draht@suse.de> wrote:
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
I disagree - having both the systemd service file and the /etc/init.d file present on an installed machine causes confusion, both at a system level (eg. different answers to /etc/init.d/SuSEfirewall2 status and systemctl status SuSEfirewall) and at a sysadmin level ("What command do I use to do X?" - we don't want to have 2 different commands with 2 different results serving the same purpose)
I agree with the argument that having the sysVinit script is good for non-systemd build targets, but for openSUSE 13.2 and beyond we use systemd, and in our distro, we should only be using systemd unit files
Don't we have some nice macros that give us systemd unit files for some build targets and includes sysVinit files for others? if not..maybe that's an approach we can take.
A suggestion for factory (13.2) and the upcomming SLE 12: put the sysVinit scripts in %doc, at least for the next release. That would remove them from /etc/init.d/ but preserving them for easy access if needed because the original script had features that aren't realised for systemctl / service yet. See post about scriptlets for that (was somewhere in the last four weeks on this list, I believe) - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2014-04-09 22:53, Richard Brown wrote:
On 9 April 2014 18:28, Roman Drahtmueller <draht@suse.de> wrote:
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
I disagree - having both the systemd service file and the /etc/init.d file present on an installed machine causes confusion, both at a system level (eg. different answers to /etc/init.d/SuSEfirewall2 status and systemctl status SuSEfirewall) and at a sysadmin level ("What command do I use to do X?" - we don't want to have 2 different commands with 2 different results serving the same purpose)
Notice that there is no "/etc/init.d/SuSEfirewall2" file. Telcontar:~ # ls /etc/init.d/* | grep -i fire Telcontar:~ # There is this, instead: Telcontar:~ # l /sbin/rcSuSEfirewall2 lrwxrwxrwx 1 root root 25 Feb 25 22:08 /sbin/rcSuSEfirewall2 -> /usr/sbin/rcSuSEfirewall2* Telcontar:~ # l /usr/sbin/rcSuSEfirewall2 lrwxrwxrwx 1 root root 7 Feb 25 22:08 /usr/sbin/rcSuSEfirewall2 -> service* Telcontar:~ # Telcontar:~ # l /usr/sbin/service -rwxr-xr-x 1 root root 3649 Jan 27 09:33 /usr/sbin/service* Telcontar:~ # rpm -qf /usr/sbin/service aaa_base-13.1-16.34.1.x86_64 Telcontar:~ # Ie, there is no "SuSEfirewall2" init script, it is something else that "emulates it". And SuSEfirewall2 is not in the list of packages posted by Ludwig Nussel. Other packages, like "postfix", which is on the list, do have a real init script, at least in 13.1, and also a service file. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 10 April 2014 02:24, Carlos E. R. <robin.listas@telefonica.net> wrote:
Notice that there is no "/etc/init.d/SuSEfirewall2" file.
Telcontar:~ # ls /etc/init.d/* | grep -i fire Telcontar:~ #
There is this, instead:
Telcontar:~ # l /sbin/rcSuSEfirewall2 lrwxrwxrwx 1 root root 25 Feb 25 22:08 /sbin/rcSuSEfirewall2 -> /usr/sbin/rcSuSEfirewall2* Telcontar:~ # l /usr/sbin/rcSuSEfirewall2 lrwxrwxrwx 1 root root 7 Feb 25 22:08 /usr/sbin/rcSuSEfirewall2 -> service* Telcontar:~ #
Telcontar:~ # l /usr/sbin/service -rwxr-xr-x 1 root root 3649 Jan 27 09:33 /usr/sbin/service* Telcontar:~ # rpm -qf /usr/sbin/service aaa_base-13.1-16.34.1.x86_64 Telcontar:~ #
Ie, there is no "SuSEfirewall2" init script, it is something else that "emulates it". And SuSEfirewall2 is not in the list of packages posted by Ludwig Nussel.
I mentioned SuSEfirewall because of my recent experience looking into Bug 869386 where multiple methods of running SuSEfirewall caused much confusion and problem https://bugzilla.novell.com/show_bug.cgi?id=869386 So the scenario was fresh in my mind, even if not 100% accurate for this discussion, I still think it's illustrative of why we only should have 1 way of starting/stopping a service (with other methods, eg. rc$foo, being aliases) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown wrote:
On 9 April 2014 18:28, Roman Drahtmueller <draht@suse.de> wrote:
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
I disagree - having both the systemd service file and the /etc/init.d file present on an installed machine causes confusion, both at a system level (eg. different answers to /etc/init.d/SuSEfirewall2 status and systemctl status SuSEfirewall) and at a sysadmin level ("What command do I use to do X?" - we don't want to have 2 different commands with 2 different results serving the same purpose)
Then get rid of the systemd interface -- it is confusing. No new commands for everyone to learn, no new "everything is different" problems -- I noted that even samba was recently called out for not being compatible with systemd's "quirks" and requirements -- of course the fact that it's been a working project for 15+ years is inconsequential. All must adapted to the new dominator.... *blech*.
I agree with the argument that having the sysVinit script is good for non-systemd build targets, but for openSUSE 13.2 and beyond we use systemd, and in our distro, we should only be using systemd unit files
Why? Because you will feel uncomfortable and insecure if anyone is still running sysVinit on their 13.2 system? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Fri, Apr 11, 2014 at 02:03:52PM -0700, Linda Walsh wrote:
Richard Brown wrote:
On 9 April 2014 18:28, Roman Drahtmueller <draht@suse.de> wrote:
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
I disagree - having both the systemd service file and the /etc/init.d file present on an installed machine causes confusion, both at a system level (eg. different answers to /etc/init.d/SuSEfirewall2 status and systemctl status SuSEfirewall) and at a sysadmin level ("What command do I use to do X?" - we don't want to have 2 different commands with 2 different results serving the same purpose)
Then get rid of the systemd interface -- it is confusing. No new commands for everyone to learn, no new "everything is different" problems -- I noted that even samba was recently called out for not being compatible with systemd's "quirks" and requirements -- of course the fact that it's been a working project for 15+ years is inconsequential. All must adapted to the new dominator.... *blech*.
About which issue are you talking? That systemd is a bit fast with starting the daemons and therefore we get in the syslog lines like like the following: PID file /run/samba/winbindd.pid not readable (yet?) See https://bugs.freedesktop.org/show_bug.cgi?id=66641 and https://bugzilla.redhat.com/show_bug.cgi?id=911819 Systemd only is a bit fast. If that's what you have in mind go and file a bugreport and I'm quite sure it will get closed with the reason: it's a feature and not a bug. There are much more broken and important things to work on. But feel free to offer real arguments in bugzilla. You're aware that the service <service-name> <command> syntax is still the same as before? And even tab completion works for the service name. The rc<service_name> sym links also work. All you no longer have is /etc/init.d/<service-name> If it's something different we need a bug report. Please be this nice and report the BUG ID back to this thread and also add to the bug report a link to the thread at http://lists.opensuse.org/opensuse-factory What we don't need are long endless, useless, and fruitless discussions. In particular now several releases after we made the switch to systemd as the only init system. And the real hard work now _is_ done.
I agree with the argument that having the sysVinit script is good for non-systemd build targets, but for openSUSE 13.2 and beyond we use systemd, and in our distro, we should only be using systemd unit files
Why? Because you will feel uncomfortable and insecure if anyone is still running sysVinit on their 13.2 system?
To keep it simple and stupid. To focus on one system to start services. To nail as many issue as possible. And we made the migration quite smooth. With openSUSE we had two systems available for quite some time. Check the Debian side and their discussion regarding systemd and see the comments from the upstart inventor after they decided to go with systemd too. See also the hard work and count the many hours spent on systemd to get it to the current level of quality as we have with openSUSE. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
El 12/04/14 13:26, Lars Müller escribió:
That systemd is a bit fast with starting the daemons and therefore we get in the syslog lines like like the following:
PID file /run/samba/winbindd.pid not readable (yet?)
See https://bugs.freedesktop.org/show_bug.cgi?id=66641 and https://bugzilla.redhat.com/show_bug.cgi?id=911819
Systemd only is a bit fast.
If that's what you have in mind go and file a bugreport and I'm quite sure it will get closed with the reason: it's a feature and not a bug. There are much more broken and important things to work on. But feel free to offer real arguments in bugzilla.
This is a known race condition, present in almost all traditional forking daemons. systemd handles it just fine by watching the PID file and marking the service as failed if it does not show up in a certain amount of time, the message that is emitted is for developers to know this problem exist. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, On Wed, Apr 09, 2014 at 06:28:12PM +0200, Roman Drahtmueller wrote:
Scanning through Factory logs I see that rpmlint found the following packages that have both a systemd service file as well as an init script. Since the latter is useless in Factory as it's shadowed by the service file the init script can be removed resp not installed:
I disagree.
Me too as Ludwig is right. ;)
Don't remove the init script from the source to allow for it to be available for non-systemd build targets/products. Nope, not everything is systemd.
Having both an init script and a service file does not harm. The interception nicely says that the call was redirected. See backwards compatibility ("rcpostfix restart") for management scripts.
Having an init script and not needing it is better than needing it and not having it. Apparently, it doesn't harm, but rather helps.
It's possible to implement this in a conditional way and by this we're able to make both sides happy and have the spec file cleaned up too. %if 0%{?suse_version} > 1220 install the systemd service file ln -s ../../%{_sbindir}/service %{buildroot}/%{_sbindir}/rc${srv_name} %else install the old init script ln -s <old init script> %{buildroot}/%{_sbindir}/rc${srv_name} %endif See network:samba:STABLE/samba/samba.spec for example. The build system will complain about a no longer fitting package filelist. But that's easy to handle by the same condition. https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines had been quite of help to me. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Roman Drahtmueller wrote:
Scanning through Factory logs I see that rpmlint found the following packages that have both a systemd service file as well as an init script. Since the latter is useless in Factory as it's shadowed by the service file the init script can be removed resp not installed:
I disagree.
Don't remove the init script from the source to allow for it to be available for non-systemd build targets/products. Nope, not everything is systemd.
Well, the truth is that there is no alternative init system in Factory. It doesn't make sense to keep the script around for sentimental reasons or because some random build service project may need it. In Factory it's just dead code. If you think the init script still is the better way to launch your daemon then feel free to remove the service file. Having both at the same time doesn't make sense though. In case the init script provides extra action not supported by systemd you may now use the legacy actions feature to implement those actions as external scripts: http://lists.opensuse.org/opensuse-factory/2014-03/msg00378.html (now also documented in wiki) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 10 of April 2014 08:58:55 Ludwig Nussel wrote:
Roman Drahtmueller wrote:
Don't remove the init script from the source to allow for it to be available for non-systemd build targets/products. Nope, not everything is systemd.
Well, the truth is that there is no alternative init system in Factory. It doesn't make sense to keep the script around for sentimental reasons or because some random build service project may need it. In Factory it's just dead code.
Packages from the devel projects are built against other targets as well, not only against Factory. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Carlos E. R. -
Cristian Rodríguez -
Lars Müller -
Linda Walsh -
Ludwig Nussel -
Michal Kubecek -
Patrick Shanahan -
Richard Brown -
Roman Drahtmueller -
Yamaban