Dne Pá 16. ledna 2015 17:39:30, Andrei Borzenkov napsal(a):

On Fri, Jan 16, 2015 at 5:23 PM, 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?

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

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 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.

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

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

В Fri, 16 Jan 2015 23:19 +0100 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.

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

On Fri, 16 Jan 2015 22:21, 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)

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

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 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

В Fri, 16 Jan 2015 23:17:11 +0100 Luca Beltrame пишет:

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

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

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

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

В Sun, 18 Jan 2015 12:17:06 +0100 Raymond Wooninck пишет:

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 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

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

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.

http://lwn.net/Articles/628542/.

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

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 -- 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

В Mon, 19 Jan 2015 18:19:11 +0100 Christian Boltz пишет:

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, 19 Jan 2015 19:30, Dimstar / Dominique Leuenberger 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 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 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

Hello, Am Montag, 19. Januar 2015 schrieb Andrei Borzenkov:

В Mon, 19 Jan 2015 18:19:11 +0100 Christian Boltz пишет:

...

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

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