[opensuse-factory] Checking and failing build of packages with initscripts on Factory
Hello people, With release of 13.2 we marked 5 releases that utilize systemd as default init. There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works. What do you think? Should I do the rpmlint check? Tom
On Fri, Jan 16, 2015 at 5:23 PM, Tomáš Chvátal <tchvatal@suse.cz> wrote:
Hello people,
With release of 13.2 we marked 5 releases that utilize systemd as default init.
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
What do you think? Should I do the rpmlint check?
If it still kinda works what is the reason? Realistically you will not be able to drop support for initscripts in foreseeable future. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne Pá 16. ledna 2015 17:39:30, Andrei Borzenkov napsal(a):
On Fri, Jan 16, 2015 at 5:23 PM, Tomáš Chvátal <tchvatal@suse.cz> wrote:
Hello people,
With release of 13.2 we marked 5 releases that utilize systemd as default init.
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
What do you think? Should I do the rpmlint check?
If it still kinda works what is the reason? Realistically you will not be able to drop support for initscripts in foreseeable future.
Kinda works mean might work and might not in some cases. It is not about dropping support for them in user software rather to get the maintainers in Factory to really migrate properly. Tom
On Friday 16 of January 2015 15:23:34 Tomáš Chvátal wrote:
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
Or it's because we were repeatedly assured that we are not going to be pushed into replacing init scripts by systemd unit files. Looks like I was right when I had my doubts about that. :-(
What do you think? Should I do the rpmlint check?
My answer is "definitely not". Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le 16/01/2015 18:41, Michal Kubecek a écrit :
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works. Or it's because we were repeatedly assured that we are not going to be
On Friday 16 of January 2015 15:23:34 Tomáš Chvátal wrote: pushed into replacing init scripts by systemd unit files. Looks like I was right when I had my doubts about that. :-(
What do you think? Should I do the rpmlint check? My answer is "definitely not".
Michal Kubeček
I moved a large part of packages from Factory to systemd init scripts. What I can say is, for the rest of not yet moved packages, a large part of service files are available in Fedora or in ArchLinux. It is possible. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 16 of January 2015 18:43:52 denisart benjamin2 wrote:
I moved a large part of packages from Factory to systemd init scripts. What I can say is, for the rest of not yet moved packages, a large part of service files are available in Fedora or in ArchLinux. It is possible.
It's not about being possible. When systemd proponents wanted to drop sysvinit, they kept saying "don't worry, init scripts work fine with systemd". When I was concerned that sooner or later, maintainers will be pushed by OBS check scripts to replace init scripts by systemd unit files, I was told it's not going to happen. Year (more or less) later, a proposal for a rpmlint check is on the table. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-16 19:21, Michal Kubecek wrote:
When systemd proponents wanted to drop sysvinit, they kept saying "don't worry, init scripts work fine with systemd". When I was concerned that sooner or later, maintainers will be pushed by OBS check scripts to replace init scripts by systemd unit files, I was told it's not going to happen. Year (more or less) later, a proposal for a rpmlint check is on the table.
Those are two separate issues. Like motorways permitting certain slow speeds, and getting lightflashed by others for actually driving slow. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 16 of January 2015 20:00:50 Jan Engelhardt wrote:
On Friday 2015-01-16 19:21, Michal Kubecek wrote:
When systemd proponents wanted to drop sysvinit, they kept saying "don't worry, init scripts work fine with systemd". When I was concerned that sooner or later, maintainers will be pushed by OBS check scripts to replace init scripts by systemd unit files, I was told it's not going to happen. Year (more or less) later, a proposal for a rpmlint check is on the table.
Those are two separate issues. Like motorways permitting certain slow speeds, and getting lightflashed by others for actually driving slow.
The thing is I was promised I wouldn't be flashed. Now, when it's about to happen, I'm trying to remind that promise (without much hope about for how long the promise will be kept). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 16 of January 2015 20:00:50 Jan Engelhardt wrote:
On Friday 2015-01-16 19:21, Michal Kubecek wrote:
When systemd proponents wanted to drop sysvinit, they kept saying "don't worry, init scripts work fine with systemd". When I was concerned that sooner or later, maintainers will be pushed by OBS check scripts to replace init scripts by systemd unit files, I was told it's not going to happen. Year (more or less) later, a proposal for a rpmlint check is on the table.
Those are two separate issues. Like motorways permitting certain slow speeds, and getting lightflashed by others for actually driving slow.
Actually, read the subject carefully: it says "failing build", not just issuing a warning. That's no lightflashing, that's forcing one out of the road. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Kubecek wrote:
Or it's because we were repeatedly assured that we are not going to be pushed into replacing init scripts by systemd unit files. Looks like I was right when I had my doubts about that. :-(
As openSUSE in its recent versions only supports systemd, I'm not sure where the problem lies. (This is a honest statement, please don't misunderstand it as flaming) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 16, 2015 at 10:21:34PM +0100, Luca Beltrame wrote:
Michal Kubecek wrote:
Or it's because we were repeatedly assured that we are not going to be pushed into replacing init scripts by systemd unit files. Looks like I was right when I had my doubts about that. :-(
As openSUSE in its recent versions only supports systemd, I'm not sure where the problem lies. (This is a honest statement, please don't misunderstand it as flaming)
As I wrote three times so far: in the attempt to break the promise that package maintainers wouldn't be pushed to replace init scripts by systemd unit files. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Kubecek wrote:
As I wrote three times so far: in the attempt to break the promise that package maintainers wouldn't be pushed to replace init scripts by systemd unit files.
I reinstate my question: why keep init scripts? There may be reasons beyond "it was like this" and "systemd forced down our throats" or "there was a probmise". I'm interested in reading those other reasons. (On my personal side, I find unit files much better to maintain, but my own universe is not statistically signficant.) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 16 Jan 2015 23:19 +0100 Luca Beltrame <lbeltrame@kde.org> пишет:
Michal Kubecek wrote:
As I wrote three times so far: in the attempt to break the promise that package maintainers wouldn't be pushed to replace init scripts by systemd unit files.
I reinstate my question: why keep init scripts? There may be reasons beyond "it was like this" and "systemd forced down our throats" or "there was a probmise". I'm interested in reading those other reasons.
This is backwards. Why *replace* them? Do not touch what is not broken. Why you want to force maintainers to waste time on replacement when current initscripts work? Do maintainers have nothing better to do?
(On my personal side, I find unit files much better to maintain, but my own universe is not statistically signficant.)
Keyword here is "force". By any means, replace initscripts with unit files in your packages - at your discretion when it best suits you. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 16.01.2015 um 23:19 schrieb Luca Beltrame:
Michal Kubecek wrote:
As I wrote three times so far: in the attempt to break the promise that package maintainers wouldn't be pushed to replace init scripts by systemd unit files.
I reinstate my question: why keep init scripts? There may be reasons beyond "it was like this" and "systemd forced down our throats" or "there was a probmise". I'm interested in reading those other reasons.
Once no package in the distribution is relying on init scripts, the next "logical" step ("logical" from the POV of systemd lovers) would be to remove support for init scripts. Apart from that, once init scripts are only used by external packages, bugs in the code will not be found nor fixed.
(On my personal side, I find unit files much better to maintain, but my own universe is not statistically signficant.)
I personally also like that I can now write simple system services that just output their log file to stdout and don't have to take care of daemon(3) and similar stuff. However, as a package maintainer, if I have a working init script (for a nontrivial service), why break that and reinvent the wheel? Just look at ntp apache and ypbind (three random examples where I suffered badly), what crazy stuff needed to be done to make them "systemd-compliant" and how many bugs were introduced in the process (and AFAICT no old bug was solved by it). Why no just keep the init scripts for those? Surely could not been more painful. That was purely for political reasons. Exactly those politics games the systemd-critics were opposed to from the beginning. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 16 Jan 2015 22:21, Luca Beltrame <lbeltrame@...> wrote:
Michal Kubecek wrote:
Or it's because we were repeatedly assured that we are not going to be pushed into replacing init scripts by systemd unit files. Looks like I was right when I had my doubts about that. :-(
As openSUSE in its recent versions only supports systemd, I'm not sure where the problem lies. (This is a honest statement, please don't misunderstand it as flaming)
Warning, rant ahead. For most services / deamons systemd is limiting their functionality, but just enough to get them working for most of the use-cases. Now, with sysVinit scripts is was easy to go beyond pure 'standard' (start|stop|restart|reload|status) and implement options as-needed. E.g. a clear-cache option for a proxy. Or specify a order to load the scripts on runlevel changes. And all that was working for more than thirty years. Now there is a 'replacement' that is forced down our throats, that is NOT clear and easy to understand, that has masses of missing features, a unorganised dung-heap laughingly called documentation, and during the time you turn your head, an other prior seperate aspect of the system is pulled into this beast. Frustation, Anger, and Irriation is the result. IMHO if systemd would have been developed seperate until at least version 210, and would come with a near perfect documentation, the aceptance would have been much better. In a way it is similar to the change from KDE3 to KDE4, or Gnome2 to Gnome3, we, the users where given unready, half regurgitated pieces of shitty code that some marketing gurus hyped beyond the pale. So, we the users fear a repeat of all that, and with full right to do so: | "Those that will not learn from the errors | of the past are doomed to repeat them." Give us better software and clear documentation. Keep that "early adopters" shit to a niche where it will not harm the masses, like all other daily-devel-snapshot, alpha, or beta software. That's my 2ct. - Yamaban -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Yamaban wrote:
For most services / deamons systemd is limiting their functionality, but just enough to get them working for most of the use-cases.
I said, it wasn't meant as flaming, and I got back a rant/flame. No matter what the rant is, "forced" or not, openSUSE supports only systemd. So my question is, and it is a *honest* question (please don't reply with "forced down etc...", it makes discussion on this list even more demotivating than what normally is, and that's a big understatement), why keep init scripts instead of systemd units? There may be legitimate cases. This reply is not one of them. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 16, 2015 at 11:17:11PM +0100, Luca Beltrame wrote:
openSUSE supports only systemd. So my question is ... why keep init scripts instead of systemd units?
My answer will be a bit longer so if you are impatient, skip to "TL;DR" below. About month ago, I installed 13.1 on an e-mail server with amavisd and additional package named amavisd-milter. In amavisd-new package, there is both a systemd unit file and an init script. The init script works perfectly and if amavisd-milter is present, it's started before amavisd itself. The systemd unit file kind of tries to do the same but it's broken somehow so that amavisd-milter is started but once "rcamavis start" finishes, it's not running any more (without any clue in the log). I have no idea why and I have no idea how to debug it (if the init script was broken, it would be much easier). So I worked around the issue by removing the systemd unit file so that the init script is used instead. Now imagine I would be forced to replace the init script by a systemd unit file in a package I'm maintaining. If something goes wrong, I would have no idea how to fix it or even how to debug it. But I would still be responsible for fixing it. If a bug on daemon start was reported, it would be assigned to me and I would be expected to fix it somehow. That's a situation I don't want to face - and I'm not going to. TL;DR There are package maintainers who understand their packages and take care of them but they don't understand systemd unit files and/or systemd itself and its quirks. And they don't have any intention to. What Tomáš proposed would mean they would have to (a) formally take responsibility for something they can't be actually responsible for, (b) resign on their maintainership or even (c) let the package be dropped from the distribution if noone else is able / willing to take over. When I raised my concern that once sysvinit would be dropped, it would be only matter of time before a check is added pushing maintainers to replace init scripts by systemd unit file, the answer was like "Why would we do that? The init scripts will still work." So that's the question you should really ask, not why keep init scripts but why force maintainers to replace them. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-16 23:50, Michal Kubecek wrote:
About month ago, I installed 13.1 on an e-mail server with amavisd and additional package named amavisd-milter. In amavisd-new package, there is both a systemd unit file [...] The systemd unit file kind of tries to do the same but it's broken somehow so that amavisd-milter is started but once "rcamavis start" finishes, it's not running any more (without any clue in the log). I have no idea why and I have no idea how to debug it
There is no excuse for a daemon to exit with non-zero status and not tell you, through stderr, syslog or a custom logfile (e.g. /var/log/squid/cache.log) why it did so. One can prepend strace into the ExecStart= line, or `screen -d -m gdb /usr/bin/foo --args whatever`. Basically the same you would do if the program exited silently under initscript context.
When I raised my concern that once sysvinit would be dropped, it would be only matter of time before a check is added pushing maintainers to replace init scripts by systemd unit file, the answer was like "Why would we do that? The init scripts will still work."
An incentive to actually learn working with systemd, and how to debug program startup issues. It will be very much valued in the coming years, as there will be more and more units (outside openSUSE too) ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Jan 17, 2015 at 12:08:17AM +0100, Jan Engelhardt wrote:
On Friday 2015-01-16 23:50, Michal Kubecek wrote:
About month ago, I installed 13.1 on an e-mail server with amavisd and additional package named amavisd-milter. In amavisd-new package, there is both a systemd unit file [...] The systemd unit file kind of tries to do the same but it's broken somehow so that amavisd-milter is started but once "rcamavis start" finishes, it's not running any more (without any clue in the log). I have no idea why and I have no idea how to debug it
There is no excuse for a daemon to exit with non-zero status and not tell you, through stderr, syslog or a custom logfile (e.g. /var/log/squid/cache.log) why it did so.
All I was able to find out indicated that it didn't really exit but rather was killed. By whom and why... no idea.
An incentive to actually learn working with systemd, and how to debug program startup issues. It will be very much valued in the coming years, as there will be more and more units (outside openSUSE too)
Yes, for completeness, that would be option (d). What I think about it should be clear from the fact that I didn't even mention it. There are too many topics I find much more interesting and much more useful (for me) to learn than this. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 16, 2015 at 7:17 PM, Luca Beltrame <lbeltrame@kde.org> wrote:
Yamaban wrote:
For most services / deamons systemd is limiting their functionality, but just enough to get them working for most of the use-cases.
I said, it wasn't meant as flaming, and I got back a rant/flame. No matter what the rant is, "forced" or not, openSUSE supports only systemd. So my question is, and it is a *honest* question (please don't reply with "forced down etc...", it makes discussion on this list even more demotivating than what normally is, and that's a big understatement), why keep init scripts instead of systemd units?
Because they work, and initscripts are a supported method of service description in systemd, that should be reason enough not to make packages fail. IOW, if an rpmlint rule were to be added, it should be with a really low badness. On Fri, Jan 16, 2015 at 7:54 PM, Jan Engelhardt <jengelh@inai.de> wrote:
On Friday 2015-01-16 22:54, Yamaban wrote:
Now, with sysVinit scripts is was easy to go beyond pure 'standard' (start|stop|restart|reload|status) and implement options as-needed. E.g. a clear-cache option for a proxy.
Yeah, see where that got us. That clear-cache command would only be supported on a handful of distributions (hardly more than one). Howto documents would have to explain one different method for every distribution. Remember rcNAME, "start-stop-daemon" and "service". Or "chkconfig" and "insserv"[*]. One available on Debian, the other on Fedora -- or something in that ballpark.
Still, there is a straightforward way to implement such a feature with initscripts. On Fri, Jan 16, 2015 at 7:54 PM, Jan Engelhardt <jengelh@inai.de> wrote:
Now there is a 'replacement' that is forced down our throats, that is NOT clear and easy to understand, that has masses of missing features,
Don't forget all the missing features of sysvinit.
Take a look at AppArmor. I'm not its maintainer, and its maintainer probably will tell a more accurate story, but IMV there's another reason to keep initscripts around: it has been almost 2 years since the idea of ExecStatus (something that would provide some of the missing functionality for AppArmor) was raised, was not blatantly rejected by systemd folks, and yet is yet to reach us. In the meanwhile, systemd has been expanding its reach way beyond what service unit files do, so it's not a lack of manpower. A reason to keep using initscripts thus is that they get more maintenance. Certainly an rpmlint rule cannot hope to evaluate those motives, and they would just add noise to the build. Why bother? The effort is better spent uploading bug reports mentioning the deficiencies on the existing initscripts. If and when the solution to those issues is creating a systemd unit files, then its maintainer will consider it. I don't see a value to adding units for the sake of units. Is there one? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 16 Jan 2015 23:17:11 +0100 Luca Beltrame <lbeltrame@kde.org> пишет:
No matter what the rant is, "forced" or not, openSUSE supports only systemd.
And systemd supports initscripts. Officially. Even upstream -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-01-16 22:54, Yamaban wrote:
Now, with sysVinit scripts is was easy to go beyond pure 'standard' (start|stop|restart|reload|status) and implement options as-needed. E.g. a clear-cache option for a proxy.
Yeah, see where that got us. That clear-cache command would only be supported on a handful of distributions (hardly more than one). Howto documents would have to explain one different method for every distribution. Remember rcNAME, "start-stop-daemon" and "service". Or "chkconfig" and "insserv"[*]. One available on Debian, the other on Fedora -- or something in that ballpark. Good riddance. [[*] Some of those were standardized by LSB, but I would claim it hardly got used in day-to-day use.]
Now there is a 'replacement' that is forced down our throats, that is NOT clear and easy to understand, that has masses of missing features,
Don't forget all the missing features of sysvinit.
| "Those that will not learn from the errors | of the past are doomed to repeat them."
Give us better software and clear documentation.
Do not ask what your projects can do for you. Ask what you can do for your projects. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Luca Beltrame wrote:
Michal Kubecek wrote:
Or it's because we were repeatedly assured that we are not going to be pushed into replacing init scripts by systemd unit files. Looks like I was right when I had my doubts about that. :-(
As openSUSE in its recent versions only supports systemd, I'm not sure where the problem lies. (This is a honest statement, please don't misunderstand it as flaming)
Um... Why should all the package maintainers be forced to removed any compatiblity options with non-systemD systems? I've taken suse rpm's and rebuilt them on cygwin, but if you really want to show me the benefits of systemd, then show me it working and supporting seamless compat on Windows, BSD-compat systems, as well as any and all of the other systems out there that won't be seeing systemD anytime in the near future. That's the main reason. The rest is a bit of a reaction to seeing/imagining too many dystopian futures... --- This attitude of removing any option but "my" option (my=those who like forcing their options down others' throats) because they won't tolerate a free society is what gives me the most incentive to resist *anything* they might suggest -- because their intentions are to narrow, restrict and control my choices to their satisfaction. As for openSUSE supporting only systemd recently? I've tried, as much as possible to stay with things that I understand and can fix w/o too much hassle. The concept of locking down my system to enable vendors complete control over my machine so I can't fix my system makes it "no longer my system". Users will just be 'renters' from those who sell locked-down systems. Maybe future users won't mind as self-reliance is bred out of the population (its a dangerous trait), but how many on this list would be happy living their lives being taken care of in a nursing home? For those who (for better or worse) live on our computers and on line, the above actions seem very similar to condemning us to being good little consumer's -- slaves to corporate whim. Ok, when looking at the future, I tend to sometimes use a bit of hyperbole, though I oft' wonder how strongly those in the future will ask why we didn't do anything to stop such a direction when it was nascent. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne Pá 16. ledna 2015 15:23:34, Tomáš Chvátal napsal(a):
Hello people,
With release of 13.2 we marked 5 releases that utilize systemd as default init.
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
What do you think? Should I do the rpmlint check?
Let me try address the concerns here rather than reply individualy: * Removing the initscripts will kill the support for other inits: - we already killed other init systems, there is only one system currently and that is systemd. If we were implementing Gentoo's openRC I would be pushing the same way to write scripts in its code, even tho it is too like systemd capable of runing plain sysvinit scripts. - even with your compat goal you are basically f***ed because more than 80% * There was promise that inits will keep working - there was promise that systemd will run initscript for external stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time. - for package maintainers, well you have to learn the bits of systemd if you really are supposed to maintain some initscripts, because otherwise you have no clue what is happening regardless if you used service or sysvinit to get there. So for Factory it is actually desired, as it is our showroom, to systemd properly without relying on compat codepaths (the same like we should use ip tool instead of ifconfig in our tools even if we still have ifconfig around for oldlovers :)) * It is complex to write services - I don't remember seeing many posts where people actually asked on opensuse-packaging (or for internal people asking pack team) for help or guidance about the scripts or for factical help with them. - To those who internaly asked I am pretty sure we helped all and explained why we did what, so in long run they ough to be able maintain their packages better, because suprisingly they might know more about systemd - In most cases the services are actually cleaner, heck even in gentoo we admited that so please stop using this moot point. Now why really we should do it: * Using native syntax of the system we use should help us avoid corner cases which are even with best effort somewhere. Overall you didn't present any really valid reason for not doing it so here are the ones I am thinking about: * it can assplode and kill way to many software than expected but what for we have staging projects - basically my rpmlint update won't get to factory before we fix the core packages anyway, where i can even promise to find a time and fix most * there can be more failed packages than anticipated - well even if we identify them we can actually do sprint to copy them from archlinux/fedora to incorporate, any volunteers here? Cheers Tom
On Sat, Jan 17, 2015 at 08:34:29PM +0100, Tomáš Chvátal wrote:
* There was promise that inits will keep working - there was promise that systemd will run initscript for external stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
No. The promise was that package maintainers won't be pushed into replacing init scripts by systemd unit files. In other words, that what you plan now woudn't happen. For the record, I never believed this promise; but I would really like to be wrong.
Now why really we should do it: * Using native syntax of the system we use should help us avoid corner cases which are even with best effort somewhere.
That's just an empty phrase without any actual technical point. Quite the contrary, forcing the replacement is what would bring unnecessary risk of regressions. Again, in reasonable projects, people need to have good reasons _for_ a change, not "we change it because we find it cool, unless you bring strong reasons to keep things as they are".
Overall you didn't present any really valid reason for not doing it so here are the ones I am thinking about:
We did. You just decided to ignore them. I wonder if there ever was anything anyone could say to stop you from going on with your plan. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dne Ne 18. ledna 2015 10:23:26, Michal Kubecek napsal(a):
On Sat, Jan 17, 2015 at 08:34:29PM +0100, Tomáš Chvátal wrote:
* There was promise that inits will keep working
- there was promise that systemd will run initscript for external stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
No. The promise was that package maintainers won't be pushed into replacing init scripts by systemd unit files. In other words, that what you plan now woudn't happen. For the record, I never believed this promise; but I would really like to be wrong.
Care to find where that was done? If it really is like you say then okay we are sticking with status quo, where we simply slowly move to unit files based on the updates till now. The only thing announced I am aware is what I wrote above. Tom -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 18, 2015 at 10:28:27AM +0100, Tomáš Chvátal wrote:
Dne Ne 18. ledna 2015 10:23:26, Michal Kubecek napsal(a):
On Sat, Jan 17, 2015 at 08:34:29PM +0100, Tomáš Chvátal wrote:
* There was promise that inits will keep working
- there was promise that systemd will run initscript for external stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
No. The promise was that package maintainers won't be pushed into replacing init scripts by systemd unit files. In other words, that what you plan now woudn't happen. For the record, I never believed this promise; but I would really like to be wrong.
Care to find where that was done? If it really is like you say then okay we are sticking with status quo, where we simply slowly move to unit files based on the updates till now.
The only thing announced I am aware is what I wrote above.
It wasn't an official announcement so you may not find it binding. But I found e.g. this e-mail: http://lists.opensuse.org/opensuse-factory/2012-09/msg00164.html In particular, this part: This is a very ridiculous statement, sorry. The package maintainers will not be 'pushed' to drop it. Nor will any scripts ensure there are no initV scripts. That's just pure non-sense It was written by Dimstar who played and still plays an important role in the project. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 18 January 2015 11:11:10 Michal Kubecek wrote:
In particular, this part:
This is a very ridiculous statement, sorry.
The package maintainers will not be 'pushed' to drop it. Nor will any scripts ensure there are no initV scripts. That's just pure non-sense
I guess that only Dominque can answer what his intentions were, however what I have seen so far is again a big flame war against systemd. My understanding from Tomas is that he just wants to implement a rpmlint message that indicates that the package does not contain any systemd scripts despite that it has a number of init scripts. Nowhere it has been said that the package is not allowed to have initscripts, just that openSUSE would like to move on and ensure that every package that has initscripts also has systemd unit files. Again I would welcome this, as that I as user has the option to choose what startup scripts I want to use. Maybe we should even try to split those packages and let the user decide whether to install the <packagename>- initscripts or <packagename>-systemd packages. I for one would very much welcome this as that I don't think that using the display-manager initscript is really reflecting the current situation. A lot of display-managers upstream have already been ported to systemd unit files and we are actually removing them, just to keep something "hackish" in place. We either start moving towards the future and ensure that we are delivering a strong distribution or we just keep living in the past with the knowledge that one day openSUSE no longer exists as a distribution because its lost its relevance. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sun, 18 Jan 2015 12:17:06 +0100 Raymond Wooninck <tittiatcoke@gmail.com> пишет:
Nowhere it has been said that the package is not allowed to have initscripts,
Did you read the subject of this thread? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 18 January 2015 14:32:19 Andrei Borzenkov wrote:
Did you read the subject of this thread?
And this was what the original email from Tomas indicated:
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
Which clearly indicate that the packages are using the initscripts instead of systemd. So the rpmlint check would be about using systemd unit files as default, but nowhere did Tomas indicated that the initscripts needs to be dropped. So I guess we are having this tiresome email thread just because of the Subject line and nobody bothered to read the actual email ? Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 18, 2015 at 12:17:06PM +0100, Raymond Wooninck wrote:
My understanding from Tomas is that he just wants to implement a rpmlint message that indicates that the package does not contain any systemd scripts despite that it has a number of init scripts.
Read the subject, please. It clearly says "failing build".
Nowhere it has been said that the package is not allowed to have initscripts, just that openSUSE would like to move on and ensure that every package that has initscripts also has systemd unit files.
In one of the old discussions, Coolo mentioned adding a check that package doesn't have both. That's something I would understand as installing both and using only one is confusing (as I experienced recenty with amavisd-new).
I for one would very much welcome this as that I don't think that using the display-manager initscript is really reflecting the current situation. A lot of display-managers upstream have already been ported to systemd unit files and we are actually removing them, just to keep something "hackish" in place.
I believe it should be up to the package maintainers which one they want to include and - more importantly - which one they want to maintain and support. Only if there are more maintainers (or people willing to maintain a package) who do not agree, distribution managers should step in as arbiters.
We either start moving towards the future
Then we might start with not having ifconfig and friends (obsolete since kernel 2.2, i.e. 1999) or even rarp (no chance of working since kernel support was dropped in 2.3, i.e. 2001) in default installation. I once suggested that we might at least move those to a separate package which wouldn't be installed by default. Was the response "Great, let's add a check for those who still use them."? No, it was "No, we can't do that, there are still scripts using them. Rather audit all the packages, find who is using the tools and submit requests." I took it as fair point, we don't want to break things and we don't want to disturb package maintainers. If you want to get rid of obsolete tools, it's your responsibility to clean up the mess and handle the fallout. But now, when it comes to init scripts which are still officially supported way of starting services and which were needed until 12.2 (supported until January 2014), the approach proposed is to add a hard check (again, "failing build") and make package maintainers responsible for everything. Doesn't it look like a double standard?
and ensure that we are delivering a strong distribution or we just keep living in the past with the knowledge that one day openSUSE no longer exists as a distribution because its lost its relevance.
Personally, I'm afraid that a community distribution like openSUSE is more likely to lose its relevance by eager embracing of every new systemd-whateverd thrown at us and replacing its tools by those. I really don't think green wallpapers (actually, more black than green these days) and YaST would be enough to make the distribution stand out and attract people (both passive users and contributors) to it. I'm not saying keeping or dropping init scripts does much difference here. But dropping all our improvements and extensions (se this thread for an example) in favour of unification with other distributions is one small step in this general direction. And forcing maintainers who don't want to do it themselves (for whatever reason) is not going to help either. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Kubecek wrote:
small step in this general direction. And forcing maintainers who don't want to do it themselves (for whatever reason) is not going to help either.
I'm saying this once - if you want to discuss this, please move this to - project as this is OT here -: OTOH, discouraging new contributors with this kind of discussion *every* time systemd is mentioned is equally - if not more - bad. My take from this (notice, I don't mean *your* specific posts, but a condensed view taken from all the flames that occurred in the past by many different people) is to stay well away from contributing in this area, unless one has really thick skin. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2015-01-18 13:34, Michal Kubecek wrote:
Then we might start with not having ifconfig and friends
Yes please. I've been actively advocating for it since at least 2008, a patch was posted to bugzilla in 2009. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sun, 18 Jan 2015 16:49:49 +0100 (CET) Jan Engelhardt <jengelh@inai.de> пишет:
On Sunday 2015-01-18 13:34, Michal Kubecek wrote:
Then we might start with not having ifconfig and friends
Yes please. I've been actively advocating for it since at least 2008, a patch was posted to bugzilla in 2009.
http://lwn.net/Articles/628542/. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2015-01-18 17:58, Andrei Borzenkov wrote:
On Sunday 2015-01-18 13:34, Michal Kubecek wrote:
Then we might start with not having ifconfig and friends
Yes please. I've been actively advocating for it since at least 2008, a patch was posted to bugzilla in 2009.
His argumentation is ok, but won't change a thing in a system governed by labor: * user expects feature x and complains more or less loudly * existing developers tag x with low priority / are not interested * user->developer conversion rate in the universe is low => user won't get feature x anytime soon -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.01.2015 um 12:17 schrieb Raymond Wooninck:
On Sunday 18 January 2015 11:11:10 Michal Kubecek wrote:
In particular, this part:
This is a very ridiculous statement, sorry.
The package maintainers will not be 'pushed' to drop it. Nor will any scripts ensure there are no initV scripts. That's just pure non-sense
I guess that only Dominque can answer what his intentions were, however what I have seen so far is again a big flame war against systemd.
No. It's a big flame war against broken promises. Even though I personally only have technical problems with systemd and personal problems with some of its developers (or more precise: with their attitude, to a point where I refuse to work on the project, but that's a different story), I deeply understand Michal's concerns as apparently he remembers the discussion of late 2012 the same as I do: "of course you will not be forced, everything will still work, yada yada". And -- probably also the same as Michal -- I did not believe a single word back then. But still I would have appreciated to be proved wrong.
My understanding from Tomas is that he just wants to implement a rpmlint message that indicates that the package does not contain any systemd scripts despite that it has a number of init scripts. Nowhere it has been said that the package is not allowed to have initscripts, just that openSUSE would like to move on and ensure that every package that has initscripts also has systemd unit files.
Read the subject of this thread: "...failing build of packages with initscripts...", try to digest its meaning, then come back to this discussion. Sorry, but the topic here is "forbidding init scripts in openSUSE", not "print a polite message if an init script is found". -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 2015-01-18 at 12:17 +0100, Raymond Wooninck wrote:
On Sunday 18 January 2015 11:11:10 Michal Kubecek wrote:
In particular, this part:
This is a very ridiculous statement, sorry.
The package maintainers will not be 'pushed' to drop it. Nor will any scripts ensure there are no initV scripts. That's just pure non-sense
I guess that only Dominque can answer what his intentions were, however what I have seen so far is again a big flame war against systemd.
Let me try to answer that, and the way *I* would like to see this approached: let's summarize some factual statements: a) openSUSE is a systemd based distribution b) systemd benefits from using native systemd unit files c) we have packages providing sysv init scripts and systemd units d) we have packages providing only sysv init scripts e) we have packages providing only systemd units To get to the topic of the thread: I do see value in a rpmlint CHECK (Warning only) for a package that falls in category c or d (e being the 'de-facto' goal, implicit with the fact that we are producing a systemd based distribution) The check should be a WARNING, so that the users are aware of it. Nothing speaks against a scanner and a TODO wiki page, listing all the packages that emit this warning! This would give some ACTUAL tasks to work on. What we *should* start is for the review-team to be stricter on accepting *NEW* packages into our beloved distribution: if a new package can't keep up with the new technologies employed, we can probably safely argue that the maintenance of that package will suffer. I am still no fan of blocking packages that perfectly work, just because they do 'something different'. Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Samstag, 17. Januar 2015 schrieb Tomáš Chvátal:
Dne Pá 16. ledna 2015 15:23:34, Tomáš Chvátal napsal(a):
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
What do you think? Should I do the rpmlint check?
* There was promise that inits will keep working - there was promise that systemd will run initscript for external stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
Oh really? https://bugzilla.opensuse.org/show_bug.cgi?id=853019 (non-public, sorry) is about a compability problem that is even security-relevant. I reported it a year ago, and nobody did anything to fix it :-( (Well, besides the work I did myself for the workaround in the rpm %post script.) Short summary of the bugreport: always use "rcapparmor reload" to reload your profiles. NEVER use "rcapparmor restart" because that will remove AppArmor protection from currently running programs (until you restart them). Background: the systemd wrapper maps "restart" to "stop, then start", and this causes a totally different handling in the initscript - "stop" unloads all profiles and removes protection from running programs, and "start" can't apply a profile to an already running program. (The initscript itsself maps "restart" to the "reload" behaviour and therefore keeps running programs protected.) Needless to say that I only found this by luck. I wouldn't be surprised if this bug exists since the first version of the systemd initscript wrapper. I could even TL;DR this to "the systemd wrapper for initscripts causes security issues, and nobody cares to fix it" :-( I know this sounds like a rant, and actually I have to admit that it is one ;-) (at least with a real problem in mind) Nevertheless, I'll happily test a fixed wrapper. I'll also happily test an apparmor.service file if someone writes it. However the precondition to accept it is that it's also accepted upstream - *.service files are (also) meant to avoid distro-specific stuff, right? ;-) (hint: it might be a good idea to send it directly to the upstream mailinglist) Bonus points if you make "rcapparmor status" as useful as it's today with the initscript. Hint: ExecStatus is still not implemented AFAIK, and the systemd answer "I started it, so it's probably still running" is anything but useful :-(
Overall you didn't present any really valid reason for not doing it
Did I already mention that ExecStatus is still missing? Note that this would also be useful for the firewall and similar stuff that doesn't include a running process - again, the current behaviour "I started it, so it must still be running" is not a good answer. [1]
- basically my rpmlint update won't get to factory before we fix the core packages anyway, where i can even promise to find a time and fix most
Oh, was this a promise to write apparmor.service and to implement ExecStatus? ;-) Regards, Christian Boltz [1] just to avoid confusion: this "only" affects things that don't have a running process, like AppArmor or a firewall --
Genau, Office und M$-Programme haben meist alle den gleichen Stil. Stimmt, die schaffen das Kammquoting meist besonders gut. *g,d&r* [> Andre Heine und Florian Gross in suse-linux]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Jan 18, 2015 at 10:47:26PM +0100, Christian Boltz wrote:
Hello,
Am Samstag, 17. Januar 2015 schrieb Tomáš Chvátal:
Dne Pá 16. ledna 2015 15:23:34, Tomáš Chvátal napsal(a):
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
What do you think? Should I do the rpmlint check?
* There was promise that inits will keep working - there was promise that systemd will run initscript for external stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
Oh really?
https://bugzilla.opensuse.org/show_bug.cgi?id=853019 (non-public, sorry) is about a compability problem that is even security-relevant. I reported it a year ago, and nobody did anything to fix it :-(
Incorrect. I at least tried to think of a solution but did not get to any. I opened the bugreport. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 19. Januar 2015 schrieb Marcus Meissner:
On Sun, Jan 18, 2015 at 10:47:26PM +0100, Christian Boltz wrote:
Am Samstag, 17. Januar 2015 schrieb Tomáš Chvátal:
* There was promise that inits will keep working
- there was promise that systemd will run initscript for external
stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
Oh really?
https://bugzilla.opensuse.org/show_bug.cgi?id=853019 (non-public, sorry) is about a compability problem that is even security-relevant. I reported it a year ago, and nobody did anything to fix it :-( Incorrect. I at least tried to think of a solution but did not get to any.
Unfortunately, thinking about it doesn't fix it :-( Besides that - please don't try to destroy a nice rant with facts ;-) Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart instead of the current, broken behaviour systemctl foo restart -> /etc/init.d/foo stop ; /etc/init.d/foo start I know that sounds too easy ;-) I don't know the wrapper code so I can only hope and assume that it really _is_ that easy for someone who knows the code. I'm looking forward for an answer from someone more familiar with systemd ;-)
I opened the bugreport.
Thanks, that makes sense after it was discussed in public. Regards, Christian Boltz -- Linux wurde nur möglich, weil 20 Jahre Betriessystemforschung sorgfältig studiert, analysiert, diskutiert und verworfen wurden. [Ingo Molnar auf linux-kernel] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 19 Jan 2015 18:19:11 +0100 Christian Boltz <opensuse@cboltz.de> пишет:
Hello,
Am Montag, 19. Januar 2015 schrieb Marcus Meissner:
On Sun, Jan 18, 2015 at 10:47:26PM +0100, Christian Boltz wrote:
Am Samstag, 17. Januar 2015 schrieb Tomáš Chvátal:
* There was promise that inits will keep working
- there was promise that systemd will run initscript for external
stuff so you keep compatibility and can in the case still run your software. That compat is not going away and actually we really really really want it to be around for a long time.
Oh really?
https://bugzilla.opensuse.org/show_bug.cgi?id=853019 (non-public, sorry) is about a compability problem that is even security-relevant. I reported it a year ago, and nobody did anything to fix it :-( Incorrect. I at least tried to think of a solution but did not get to any.
Unfortunately, thinking about it doesn't fix it :-( Besides that - please don't try to destroy a nice rant with facts ;-)
Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart
systemd does not have notion of "restart" as first class citizen. It implements "restart" as "stop" followed by "start".
instead of the current, broken behaviour
All initscripts I am aware of implement "restart" as "stop" followed by "start". I very seriously doubt anyone will spend time for the sake of single script that decided to interpret it differently. May be this script actually misuses "restart" for "reload" here? I'm guessing - bug is non public ...
systemctl foo restart -> /etc/init.d/foo stop ; /etc/init.d/foo start
I know that sounds too easy ;-) I don't know the wrapper code so I can only hope and assume that it really _is_ that easy for someone who knows the code.
I'm looking forward for an answer from someone more familiar with systemd ;-)
I opened the bugreport.
Ah, OK. As I suspected: restart|reload|force-reload) "When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less." I guess, the obvious answer is - do not use %restart_on_update boot.apparmor in spec file, explicitly use "systemctl reload". We obviously have service whose behavior is very different to others, so it is logical to deviate from defaults.
Thanks, that makes sense after it was discussed in public.
Regards,
Christian Boltz
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-01-19 at 21:16 +0300, Andrei Borzenkov wrote:
Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart
systemd does not have notion of "restart" as first class citizen. It implements "restart" as "stop" followed by "start".
instead of the current, broken behaviour
According to LSB, 'service restart' on (sysV services!) was already declared long ago as 'stop and restart if the service is running, otherwise only start' See http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/in... for a definition. As such, there is nothing systemd invented here: it actually only implemented what LSB already defined long ago. (I know it does not help the fact that apparmor still needs it - but the correct flag in sysv times would have been 'reload': have the service reload its configuration) Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 19 Jan 2015 19:30, Dimstar / Dominique Leuenberger <dimstar@...> wrote:
On Mon, 2015-01-19 at 21:16 +0300, Andrei Borzenkov wrote:
Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart
systemd does not have notion of "restart" as first class citizen. It implements "restart" as "stop" followed by "start".
instead of the current, broken behaviour
According to LSB, 'service restart' on (sysV services!) was already declared long ago as 'stop and restart if the service is running, otherwise only start'
See http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/in... for a definition.
As such, there is nothing systemd invented here: it actually only implemented what LSB already defined long ago.
(I know it does not help the fact that apparmor still needs it - but the correct flag in sysv times would have been 'reload': have the service reload its configuration)
Cheers, Dominique
Addenum:
From specfile scripts apparmor should be called with try-reload, but systemd does not know that command.
Would the following do the job? [code] systemctl --quiet is-active apparmor && systemctl reload apparmor [/code] But then we should make sure that the actual apparmor.service file contains the needed "ExecReload=" line else it's pre-defined as SIGHUP to the process pid - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2015-01-19 at 21:05 +0100, Yamaban wrote:
On Mon, 19 Jan 2015 19:30, Dimstar / Dominique Leuenberger <dimstar@...> wrote:
On Mon, 2015-01-19 at 21:16 +0300, Andrei Borzenkov wrote:
Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart
systemd does not have notion of "restart" as first class citizen. It implements "restart" as "stop" followed by "start".
instead of the current, broken behaviour
According to LSB, 'service restart' on (sysV services!) was already declared long ago as 'stop and restart if the service is running, otherwise only start'
See http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/in... for a definition.
As such, there is nothing systemd invented here: it actually only implemented what LSB already defined long ago.
(I know it does not help the fact that apparmor still needs it - but the correct flag in sysv times would have been 'reload': have the service reload its configuration)
Cheers, Dominique
Addenum: From specfile scripts apparmor should be called with try-reload, but systemd does not know that command.
try-reload? I don't think that was ever specified as a default on sysv scripts (there was reload and force-reload)
Would the following do the job?
[code] systemctl --quiet is-active apparmor && systemctl reload apparmor [/code]
why the check? systemctl reload is not supposed to start the service if it's not running (equivalent to sysv times: it is not supposed to start the service if not running) (not to confuse with reload-or-restart: this WILL trigger a reload if possible or a 'restart', which is a 'stop and start' => resulting in a running service in the end) Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2015-01-19 21:05, Yamaban wrote:
But then we should make sure that the actual apparmor.service file contains the needed "ExecReload=" line else it's pre-defined as SIGHUP to the process pid
You are wrong. There is no such predefinition. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 19 Jan 2015 21:58, Jan Engelhardt <jengelh@...> wrote:
On Monday 2015-01-19 21:05, Yamaban wrote:
But then we should make sure that the actual apparmor.service file contains the needed "ExecReload=" line else it's pre-defined as SIGHUP to the process pid
You are wrong. There is no such predefinition.
I stand correced. Thanks. One more cause to define it. man systemd.service http://www.freedesktop.org/software/systemd/man/systemd.service.html -- "Wer lesen kann ist klar im Vorteil" -- Schade nur, das es dann so wenige wirklich tun. (Deutsch Lehrer, sechste Klasse) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2015-01-19 22:59, Yamaban wrote:
But then we should make sure that the actual apparmor.service file contains the needed "ExecReload=" line else it's pre-defined as SIGHUP to the process pid
You are wrong. There is no such predefinition.
One more cause to define it.
Absolutely not. Your suggestion does more harm than without. Some programs may not handle SIGHUP, and then exit if they get it anyway. So you just turned "reload" into "stop", more or less. Not good. Other programs, like cupsd-1.5.4, set to ignore SIGHUP. So you just turned "reload" from an informative "sorry, cups.service does not support it" error into a succeeding silent no-op. Not good. So next time, think things through first. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 19 Jan 2015 23:56, Jan Engelhardt <jengelh@...> wrote:
On Monday 2015-01-19 22:59, Yamaban wrote:
But then we should make sure that the actual apparmor.service file contains the needed "ExecReload=" line else it's pre-defined as SIGHUP to the process pid
You are wrong. There is no such predefinition.
One more cause to define it.
Absolutely not. Your suggestion does more harm than without.
Some programs may not handle SIGHUP, and then exit if they get it anyway. So you just turned "reload" into "stop", more or less. Not good.
Other programs, like cupsd-1.5.4, set to ignore SIGHUP. So you just turned "reload" from an informative "sorry, cups.service does not support it" error into a succeeding silent no-op. Not good.
So next time, think things through first.
Please do not misconstruct such from my reply, the reply only was minted for 'apparmor', and 'apparmor' alone. And I can count more than 14 'services' where SIGHUP for 'reload' would be wrong, just from Factory repo. And a signal via kill is most NOT the ideal way for a reload, as no responce code is given from the main process. If 'service' programs would be nice, they them self would implement parameters like 'stop' 'reload-config' 'reopen-logfile' and such, while detecting the 'master' process themself. But there is no such framework, sadly. - Yamaban -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 19. Januar 2015 schrieb Andrei Borzenkov:
В Mon, 19 Jan 2015 18:19:11 +0100 Christian Boltz <opensuse@cboltz.de> пишет:
Seriously: I can think of an easy and obvious solution - the wrapper should just hand over the parameter it gets to the initscript without any modification. This means: systemctl foo restart -> /etc/init.d/foo restart
systemd does not have notion of "restart" as first class citizen. It implements "restart" as "stop" followed by "start".
As default behaviour for *.service files, there's nothing wrong with that. Note that there's ExecRestart to override it. So the systemd developers know that it most be possible to override the behaviour for "restart". One more reason to allow an initscript to override it ;-)
instead of the current, broken behaviour
All initscripts I am aware of implement "restart" as "stop" followed by "start".
Then you don't know all initscripts ;-) - I'm quite sure there were or are more initscripts that have a different behaviour for restart. The point is that initscripts are shell code, which means they can do *whatever they want* - as an extreme example, "rcfoo restart" could play some music (I don't say that's a good idea, but it's possible.) Back to the serious part - doing something in a way that makes sense and avoids problems (for example not dropping AppArmor protection from running processes) is worth more than strictly following what LSB describes. The AppArmor initscript is not 100% LSB compliant because it maps restart to reload? Thanks for the information, but my server is still protected. (Well, at least if I use SYSTEMD_NO_WRAP=1.) I'm quite sure everybody prefers that over the correct implementation of restart as "stop, then start".
I very seriously doubt anyone will spend time for the sake of single script that decided to interpret it differently. May be this script actually misuses "restart" for "reload" here? I'm guessing - bug is non public ...
Systemd promised to support initscripts. For me, that includes support for slightly unusual initscripts. Part of this is to hand over parameters as specified ("restart") and not changed to something that looks right in most cases.
Ah, OK. As I suspected:
restart|reload|force-reload)
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."
Now let's think about what users want/expect when they call "rcapparmor restart": a) load updated profiles and keep running processes protected b) load updated profiles and remove protection from all running processes Yes, I'd like to hear a serious answer on this.
I guess, the obvious answer is - do not use %restart_on_update boot.apparmor in spec file, explicitly use "systemctl reload". We obviously have service whose behavior is very different to others, so it is logical to deviate from defaults.
I already do this in the rpm %post script - but still, there might be users who might (maybe "just" accidently) use "rcapparmor restart" instead of "rcapparmor reload". Regards, Christian Boltz PS: Fun fact: ExecStatus is not implemented, but it works when using an initscript. This means "systemctl status apparmor" is much more useful now than it would be after migrating to an apparmor.service. --
babelfish could be your friend here Have you tried it? It usually translates about as well as a drunken 2 year old! :-P [> scsijon and David Wright in opensuse]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 16.01.2015 um 15:23 schrieb Tomáš Chvátal:
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
Unfortunately just enforcing some policy won't work. See for example display-manager, postfix or ntpd. They appear to use systemd service files but actually the service file just starts more or less the old init script that was renamed and copied elsewhere. That's not quite the goal of the exercise IMO. The time would be better invested in important and core packages like the mentioned ones. Ie make sure they have proper startup behavior and can serve as good examples for leaf package maintainers. Also, there's a number of packages that have both a sysv init script and a service file (rpmlint check suse-systemd-shadowed-initscript). Those should decide for one or the other: apache2 avahi courier-authlib courier-imap erlang gnugk gnump3d icecast keepalived laptop-mode-tools memcached netatalk nut php5 postfix postgrey pptpd proftpd radvd sanlock ufw varnish xl2tpd
What do you think? Should I do the rpmlint check?
Well, feel free to extend CheckRCLinks.py. I wouldn't want to make it a fatal check yet though. There are likely quite some packages where the daemon itself is worse than the init script anyways :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 16.01.2015 15:23, Tomáš Chvátal wrote:
Hello people,
With release of 13.2 we marked 5 releases that utilize systemd as default init.
There are still few leaf packages using regular old initscript instead of unit files. I guess it is due to simple fact that nobody bothered nor had a reason as it still kinda works.
What do you think? Should I do the rpmlint check?
No, you should not make it fatal. It should just issue one of those numerous warnings people don't read. 1) A lot of systemd ports of sysvinit packages are trojans anyway which internally just run something similar to the original sysvinit scripts. That's what happens if you request formal compliance but nobody really cares. 2) If the packages work for systemd via sysvinit scripts, there is no need to change them. Given limited time of contributors, they would rather fix something that does not work. 3) If there are some unintended side effects of using existing sysvinit scripts, contributors have not cared until now and won't care either. Chances are, if you fail those builds the package just will disappear from factory and users will pull them from devel repos or other 3rd sources. 4) If you really want to push conversion, do the conversion work. It's really easy and well documented and if something does not work initially, I am sure people will be glad to help you. Moreover, in most cases you can just copy/paste from some zero pointer address on the internet without much thinking about what actually happens. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Sunday 18 of January 2015 18:58:45 Ralf Lang wrote:
4) If you really want to push conversion, do the conversion work.
I don't think this is a good idea. This would mean that someone who (likely) doesn't know the package, doesn't know the software, doesn't know how the daemon is started and why and what the prerequisities are, is supposed to replace init script by a systemd unit file. As previous mails indicate, their plan is to pick a unit file somewhere on the web, perhaps from some other distribution, and put it into the package. Now we don't know who wrote the unit file, whether he actually does understand the software and whether it works properly and provides all functionality provided by the init script. And whoever is doing this doesn't even know how to test the software properly. If we are lucky, they will at least try to install the package and check that the daemon(s) start(s). In most cases, this will be sufficient but sometimes we end up with a headache like infamous bnc#857372 (which also illustrates why overruling package maintainer may be a bad thing). Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I don't think this is a good idea. This would mean that someone who (likely) doesn't know the package, doesn't know the software, doesn't know how the daemon is started and why and what the prerequisities are, is supposed to replace init script by a systemd unit file. As previous mails indicate, their plan is to pick a unit file somewhere on the web, perhaps from some other distribution, and put it into the package.
Now we don't know who wrote the unit file, whether he actually does understand the software and whether it works properly and provides all functionality provided by the init script. And whoever is doing this doesn't even know how to test the software properly. If we are lucky, they will at least try to install the package and check that the daemon(s) start(s). In most cases, this will be sufficient but sometimes we end up with a headache like infamous bnc#857372 (which also illustrates why overruling package maintainer may be a bad thing).
It's still better than breaking perfectly valid builds without any fix in place. It gives us time and if done in a sane way, one by one and not in bulk, we will probably have a good chance to detect any problems. Some of us are running factory, at least for desktop and test machines. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
participants (16)
-
Andrei Borzenkov -
Christian Boltz -
Claudio Freire -
denisart benjamin2 -
Dimstar / Dominique Leuenberger -
Jan Engelhardt -
Linda Walsh -
Luca Beltrame -
Ludwig Nussel -
Marcus Meissner -
Michal Kubecek -
Ralf Lang -
Raymond Wooninck -
Stefan Seyfried -
Tomáš Chvátal -
Yamaban