[opensuse-packaging] Creating of systemd service files instead of init scripts for new packages
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Andreas
El 29/03/13 14:43, Andreas Jaeger escribió:
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
Michal Kubeček
On 02.04.2013 10:06, Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init scripts. But it's perfectly fine also to have a rpmlint warning that a package has *only* init script and Cristian adding systemd services for them - if the maintainer of the package disagrees to add it, then we can talk again.
Greetings, Stephan
Stephan Kulow wrote:
On 02.04.2013 10:06, Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init scripts. But it's perfectly fine also to have a rpmlint warning that a package has *only* init script and Cristian adding systemd services for them - if the maintainer of the package disagrees to add it, then we can talk again.
Well, the truth is that it doesn't make much sense anymore to keep the sysv scripts if there is a service file. It only adds potential code duplication and confusion. So I'd vote for having either .service files or init scripts in a package but not both. However, adding service files that break previous features or just add the init script shell code 1:1 as ExecStartPre should be avoided too.
cu Ludwig
On Wed, 3 Apr 2013 09:20, Ludwig Nussel <ludwig.nussel@...> wrote:
Stephan Kulow wrote:
On 02.04.2013 10:06, Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init scripts. But it's perfectly fine also to have a rpmlint warning that a package has *only* init script and Cristian adding systemd services for them - if the maintainer of the package disagrees to add it, then we can talk again.
Well, the truth is that it doesn't make much sense anymore to keep the sysv scripts if there is a service file. It only adds potential code duplication and confusion. So I'd vote for having either .service files or init scripts in a package but not both. However, adding service files that break previous features or just add the init script shell code 1:1 as ExecStartPre should be avoided too.
As long as there is a SLE(S|D) without systemd support you are shooting your own legs if you just "drop" all replaced sysVinit scripts.
For systems with full systemd support (12.1 and later), install the scrips as %doc in the docdir for reference (and help).
Before a drop could be considered (13.1 and following), there is more maturing needed (intoduce a .service, and get it working without troubles for a full release, e.g. a 'new' .service in 12.3 gets a moved /etc/init.d/ script as %doc in 13.1 and so on.
Similar in SLE, afer one run in a SLE service pack it could be considered to move the scripts, but what of those that modified the scripts to suit their needs?
I agree, that keeping the old sysVinit scripts beyond the end-of-life of the last sysVinit supporting SLE version (12?, 11 for sure) does not make sense, but before?
Are you trying to get the SLE support crew mad at you?
Just food for thoughts, - Yamaban.
On 04/03/2013 04:42 PM, Yamaban wrote:
On Wed, 3 Apr 2013 09:20, Ludwig Nussel <ludwig.nussel@...> wrote:
Stephan Kulow wrote:
On 02.04.2013 10:06, Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init scripts. But it's perfectly fine also to have a rpmlint warning that a package has *only* init script and Cristian adding systemd services for them - if the maintainer of the package disagrees to add it, then we can talk again.
Well, the truth is that it doesn't make much sense anymore to keep the sysv scripts if there is a service file. It only adds potential code duplication and confusion. So I'd vote for having either .service files or init scripts in a package but not both. However, adding service files that break previous features or just add the init script shell code 1:1 as ExecStartPre should be avoided too.
As long as there is a SLE(S|D) without systemd support you are shooting your own legs if you just "drop" all replaced sysVinit scripts.
Only as long as packages are build for SLE 11 - and many are not.
For systems with full systemd support (12.1 and later), install the scrips as %doc in the docdir for reference (and help).
Before a drop could be considered (13.1 and following), there is more maturing needed (intoduce a .service, and get it working without troubles for a full release, e.g. a 'new' .service in 12.3 gets a moved /etc/init.d/ script as %doc in 13.1 and so on.
No, this is really overkill in this case. Service files are not that complicated and can be easily tested.
Similar in SLE, afer one run in a SLE service pack it could be considered to move the scripts, but what of those that modified the scripts to suit their needs?
That's why you're not doing this during the lifetime of SLE 11 but introduce it directly with e.g. SLE 12.
I agree, that keeping the old sysVinit scripts beyond the end-of-life of the last sysVinit supporting SLE version (12?, 11 for sure) does not make sense, but before?
Are you trying to get the SLE support crew mad at you?
You don't need to worry about that,
Andreas
Hello,
Am Mittwoch, 3. April 2013 schrieb Andreas Jaeger:
On 04/03/2013 04:42 PM, Yamaban wrote:
Are you trying to get the SLE support crew mad at you?
You don't need to worry about that,
Does this mean you would accept the following patch in a SR to Factory? (with $something replaced by aaa_base, vim, emacs, whatever)
--- $something.spec +++ $something.spec @@ some,line @@ %build +%if 0%{?sles_version} > 10 + echo "I don't care about SLE" + exit 42 +%endif
I'm looking forward for your answer ;-)
*SCNR*
Seriously:
I know openSUSE packagers don't need to worry about SLE. This is especially true for packagers not paid by SUSE (you can't force them in any way, maybe except "I won't pay you a drink at the conference" ;-)
OTOH in the interest of working together in a friendly way, it makes sense to keep the packages SLE-compatible whenever possible ;-)
Regards,
Christian Boltz
On 04/03/2013 07:21 PM, Christian Boltz wrote:
Hello,
Am Mittwoch, 3. April 2013 schrieb Andreas Jaeger:
On 04/03/2013 04:42 PM, Yamaban wrote:
Are you trying to get the SLE support crew mad at you?
You don't need to worry about that,
Does this mean you would accept the following patch in a SR to Factory? (with $something replaced by aaa_base, vim, emacs, whatever)
--- $something.spec +++ $something.spec @@ some,line @@ %build +%if 0%{?sles_version} > 10
- echo "I don't care about SLE"
- exit 42
+%endif
No, not at all.
I do care a lot about SLE - it's one of my responsibilities - but in this specific context and how the question was asked, there's no need for Yamaban to care about SLE.
I'm looking forward for your answer ;-)
christian, are you satisfied ? ;)
*SCNR*
Seriously:
I know openSUSE packagers don't need to worry about SLE. This is especially true for packagers not paid by SUSE (you can't force them in any way, maybe except "I won't pay you a drink at the conference" ;-)
OTOH in the interest of working together in a friendly way, it makes sense to keep the packages SLE-compatible whenever possible ;-)
Sure. And supporting SLE 11 is fine - if that is wanted for a package and a valid reason to not remove an init file.
But if a package is not build for SLE 11, then why should it have an init file?
Andreas
On Wednesday 03 of April 2013 20:20EN, Andreas Jaeger wrote:
But if a package is not build for SLE 11, then why should it have an init file?
Because OpenSuSE is supposed to be a codebase for SLE12. And I don't see much sense in taking effort in carefully removing anything reminding System V init now and then making it work with System V init again several months later (yes, perhaps I'm naïve, but I still believe there will be System V init in SLE12).
Moreover, people like Coolo still claim they will be fine with someone fixing System V init support in OpenSuSE with an add-on repository. But seeing that things needed for proper System V init support are countinuously taken away from distribution even when they do not harm systemd in any way makes it kind of hard to believe that they are sincere. As I plan to devote the Hackweek to such project, I would really appreciate if people didn't deliberately make the work harder at least in the cases when it actually doesn't help anyone.
Few months ago, I expressed my fear that package maintainers are going to be pushed into removing init scripts from their packages. I have been assured this is not going to happen. Few months later, we are seriously discussing adding a warning to OBS if a package contains an init script and not letting anyone to add a new package with an init script. And everyone - or at least everyone who matters - seems to be OK with it. Well, it's hard not to see this as pushing.
Michal Kubeček
On 04/04/2013 03:23 AM, Michal Kubeček wrote:
(yes, perhaps I'm naïve, but I still believe there
will be System V init in SLE12).
Yes, you are being naive, currently, there is no way to make any future product to work without systemd without a massive effort that nobody here will do.
As I plan to devote the Hackweek to such project, I would
really appreciate if people didn't deliberately make the work harder at least in the cases when it actually doesn't help anyone.
You will be wasting your time.
It is not my place to tell you what to do, however I would suggest you pick something else.
Well, it's hard not to see this as pushing.
More than pushing, it is just an statement of fact, we are past the point of return by now.
On Thursday 04 of April 2013 03:33EN, Cristian Rodríguez wrote:
On 04/04/2013 03:23 AM, Michal Kubeček wrote:
(yes, perhaps I'm naïve, but I still believe there will be System V init in SLE12).
Yes, you are being naive, currently, there is no way to make any future product to work without systemd without a massive effort that nobody here will do.
Well, you are definitely not the one to decide that so your opinion on this is not a bit more valuable than mine. Enterprise world is much less keen to fall for bells and whistles and much less accepting to the general "we break anything anytime and it's world's job to adapt" attitude of systemd people. So I guess, there is a chance.
As I plan to devote the Hackweek to such project, I would really appreciate if people didn't deliberately make the work harder at least in the cases when it actually doesn't help anyone.
You will be wasting your time.
Even if I did, it is my right to do so. And even if the only result is that it will make OpenSuSE usable for me for eight more months, it will be worth it.
Well, it's hard not to see this as pushing.
More than pushing, it is just an statement of fact, we are past the point of return by now.
Well, forgive me not taking words of hard core systemd fan on this matter as truth revealed. :-)
But the point is different: I just wanted to remind a promise given less than half year ago which is now going to be broken.
Michal Kubeček
On 04/04/2013 03:53 AM, Michal Kubeček wrote:
Well, you are definitely not the one to decide that so your opinion on this is not a bit more valuable than mine. Enterprise world is much less keen to fall for bells and whistles and much less accepting to the general "we break anything anytime and it's world's job to adapt" attitude of systemd people. So I guess, there is a chance.
Just in case, the competitors alreadsy have RHEL 7 betas and use systemd.
Even if I did, it is my right to do so. And even if the only result is that it will make OpenSuSE usable for me for eight more months, it will be worth it.
It is not just a matter of restoring init scripts, currently you will need to "fork" gnome, kde, udev, most of the base system..
On Thursday 04 of April 2013 04:06EN, Cristian Rodríguez wrote:
Just in case, the competitors alreadsy have RHEL 7 betas and use systemd.
If RHEL 7 is going to be systemd-only, one more reason to provide both as a competetive advantage...
It is not just a matter of restoring init scripts, currently you will need to "fork" gnome, kde, udev, most of the base system..
Yes, I noticed a lot of effort has been taken to make life of those who want to use System V init harder. And unfortunately more than seldom without actually helping those using systemd... which makes me sad.
Michal Kubeček
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Yes, I noticed a lot of effort has been taken to make life of those who want to use System V init harder.
No, lot of effort has been done to integrate systemd better.
And unfortunately more than seldom without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them.
On Thursday 04 of April 2013 04:25EN, Cristian Rodríguez wrote:
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Yes, I noticed a lot of effort has been taken to make life of those who want to use System V init harder.
No, lot of effort has been done to integrate systemd better.
Not all of it. A lot of changes are only "this is not needed anymore as we have only systemd" - and such changes are being done even if keeping those things wouldn't harm systemd-only systems in any way.
And unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them.
I'm not talking about bugs. I'm talking about changes which will need to be reverted to make System V init work again and which are neither necessary nor helpful for systemd-only systems.
Michal Kubeček
On Thu, Apr 4, 2013 at 11:35 AM, Michal Kubeček mkubecek@suse.cz wrote:
On Thursday 04 of April 2013 04:25EN, Cristian Rodríguez wrote:
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Yes, I noticed a lot of effort has been taken to make life of those who want to use System V init harder.
No, lot of effort has been done to integrate systemd better.
Not all of it. A lot of changes are only "this is not needed anymore as we have only systemd" - and such changes are being done even if keeping those things wouldn't harm systemd-only systems in any way.
And unfortunately more than seldom
without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them.
I'm not talking about bugs. I'm talking about changes which will need to be reverted to make System V init work again and which are neither necessary nor helpful for systemd-only systems.
Having list of such changes somewhere would help as well.
Am 04.04.2013 09:25, schrieb Cristian Rodríguez:
On 04/04/2013 04:20 AM, Michal Kubeček wrote:
Yes, I noticed a lot of effort has been taken to make life of those who want to use System V init harder.
No, lot of effort has been done to integrate systemd better.
And unfortunately more than seldom without actually helping those using systemd... which makes me sad.
If there are bugs, we want to know so we can fix them.
Nobody fixes systemd bugs is my observation. Only new ones are added all the time :-)
My machine has been unable to shut down without sysrq-E and sometimes sysrq-I. It hangs somewhere, but because everything is totally silent it does not show any debugging output.
I have given up on reporting systemd bugs because they reappear faster than you can report them.
Right now I would appreciate a working SysV-Init implementation we had for 20 years much more than the ever changing and ever broken crap that systemd is.
And I would bet quite some money that some of the customers I'm working for will not buy SLES12 if it ships a systemd that does not run their custom init scripts without tweaking.
El 13/04/13 19:19, Stefan Seyfried escribió:
Nobody fixes systemd bugs is my observation. Only new ones are added all the time :-)
That's not true.
My machine has been unable to shut down without sysrq-E and sometimes sysrq-I. It hangs somewhere, but because everything is totally silent it does not show any debugging output.
did you enabled debugging ?
I have given up on reporting systemd bugs because they reappear faster than you can report them.
do you have examples ?
Right now I would appreciate a working SysV-Init implementation we had for 20 years much more than the ever changing and ever broken crap that systemd is.
It is not.
Am 14.04.2013 00:34, schrieb Cristian Rodríguez:
El 13/04/13 19:19, Stefan Seyfried escribió:
Nobody fixes systemd bugs is my observation. Only new ones are added all the time :-)
That's not true.
My machine has been unable to shut down without sysrq-E and sometimes sysrq-I. It hangs somewhere, but because everything is totally silent it does not show any debugging output.
did you enabled debugging ?
That's not feasible as I need to enable debugging at boot and then have lots debug information wasting cycles just to debug the shutdown 2 weeks later once a new kernel is out. Or is there a way to enable debugging just before shutdown? I have not found one.
I have given up on reporting systemd bugs because they reappear faster than you can report them.
do you have examples ?
My cryptohome does not mount every second boot. This time it was actually asking me for the password on the text console and echoing the passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times in bugzilla, but I'm just tired of it.
Forwarding to syslog-ng does not work. Only "Forwarding to syslog missed XXX messages" all the time. Wait, scrap that. Since yesterday's reboot it seems to work, only ~130 missed messages during boot, now it works. (and no, journal is not an alternative, because the performance is abysmal. "journalctl", then hitting "end" thrashes my disk for about three minutes before responding. I can grep through 3 Years worth of /var/log/messages-* in the same time).
Right now I would appreciate a working SysV-Init implementation we had for 20 years much more than the ever changing and ever broken crap that systemd is.
It is not.
Maybe it works for you, but for me it is an nondeterministic heap of crap. Latest example: Curiously after timedatectl was mentioned in this hread, I issued "timedatectl" as a nonprivileged user(!) to see what it would give me. Now I no longer can start / stop ntp and ntp is broken. WTF? (Yes, I killed all involved processes I could find in the mean time). Probably the solution will be a reboot. Systemd really brings us closer to the other "great" Desktop OS's.
Initially I was thinking that systemd was a good idea, right now I'm seriously considering switching to a busybox based home-built primitive init that *just works* in a deterministic way (I have about 20 different systems sitting in my A/V shelf, all running different busybox-based init systems just fine and very reliably). In theory, systemd should be more deterministic, but obviously it is only tested in very few different scenarios and mine (a pretty normal, moderately old laptop with bluetooth and wireless networking used and an encrypted $HOME) is not one of them. Probably it's too exotic. Encryption is only for terrorists and as such not supported :-)
At least I'll use busybox init as an alternative implementation to get the system up when systemd fails.
On Sat, Apr 13, 2013 at 8:34 PM, Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Right now I would appreciate a working SysV-Init implementation we had for 20 years much more than the ever changing and ever broken crap that systemd is.
It is not.
Maybe it works for you, but for me it is an nondeterministic heap of crap. Latest example: Curiously after timedatectl was mentioned in this hread, I issued "timedatectl" as a nonprivileged user(!) to see what it would give me. Now I no longer can start / stop ntp and ntp is broken. WTF? (Yes, I killed all involved processes I could find in the mean time). Probably the solution will be a reboot. Systemd really brings us closer to the other "great" Desktop OS's.
Initially I was thinking that systemd was a good idea, right now I'm seriously considering switching to a busybox based home-built primitive init that *just works* in a deterministic way (I have about 20 different systems sitting in my A/V shelf, all running different busybox-based init systems just fine and very reliably). In theory, systemd should be more deterministic, but obviously it is only tested in very few different scenarios and mine (a pretty normal, moderately old laptop with bluetooth and wireless networking used and an encrypted $HOME) is not one of them. Probably it's too exotic. Encryption is only for terrorists and as such not supported :-)
At least I'll use busybox init as an alternative implementation to get the system up when systemd fails.
This story reminds me of ReiserFS.
Good in theory, not so hot in practice.
I must say that after updating that old ReiserFS-based system I had (from back when Reiser was SUSE's default), it's now working quite glitch-free. No tree rebuilds have been necessary in ages.
I'd expect SystemD will become usable far far after people give up on it. All because it was introduced into distros quite prematurely.
In any case, aside from the obscurity of it, I haven't found such big roadblocks with SystemD. It has an incredibly steep learning curve though. For those used to the simplicity of SysVInit (once installed), SystemD is as obscure as Windows' registry database. I felt like that when I wanted to move kdm's startup sequence to a bit earlier (it seems to wait for way more than would be required, delaying the login screen), and for the life of me every step felt like I was going to have to ask a clairvoyant or something, because it was nigh-impossible to follow. I failed, btw, since the dependency is buried away in heaps of indirection, and changing it would have required massive restructuring of the distro's init sequence. Not to mention the error messages, SystemD must have been the golden disciple of C++ in that sense.
TBH, from what I saw, I think most of this obscurity stems from trying to keep sysvinit scripts around.
Anyway, I digress. SLES will probably end up using SystemE, a fictitious next-incarnation of SystemD, built with all the experience learned from SystemD's mistakes Like btrfs seems compared to ReiserFS. Only that will take about 5 years, if Reiser's story holds equivalent.
Until then... prepare to rebuild your tree... I mean swap your busybox quite often.
El 13/04/13 20:34, Stefan Seyfried escribió:
Am 14.04.2013 00:34, schrieb Cristian Rodríguez:
El 13/04/13 19:19, Stefan Seyfried escribió:
Nobody fixes systemd bugs is my observation. Only new ones are added all the time :-)
That's not true.
My machine has been unable to shut down without sysrq-E and sometimes sysrq-I. It hangs somewhere, but because everything is totally silent it does not show any debugging output.
did you enabled debugging ?
That's not feasible as I need to enable debugging at boot and then have lots debug information wasting cycles just to debug the shutdown 2 weeks later once a new kernel is out. Or is there a way to enable debugging just before shutdown? I have not found one.
didnt this --> http://freedesktop.org/wiki/Software/systemd/Debugging help ? are you sure the "freeze" is caused by systemd ? maybe be kernel bug..just saying...
My cryptohome does not mount every second boot. This time it was actually asking me for the password on the text console and echoing the passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times in bugzilla, but I'm just tired of it.
There were bugs, in the next iteration of systemd there are fixes included for that.
Forwarding to syslog-ng does not work. Only "Forwarding to syslog missed XXX messages" all the time.
have you considered that might be a bug in syslog-ng units and nothing to do with systemd ?
(and no, journal is not an
alternative, because the performance is abysmal. "journalctl", then hitting "end" thrashes my disk for about three minutes before responding. I can grep through 3 Years worth of /var/log/messages-* in the same time).
Since systemd 195 there have been a lot of improvements into the journal, I suggest you test and report what happends with systemd > 201
Maybe it works for you, but for me it is an nondeterministic heap of crap. Latest example: Curiously after timedatectl was mentioned in this hread, I issued "timedatectl" as a nonprivileged user(!) to see what it would give me. Now I no longer can start / stop ntp and ntp is broken. WTF? (Yes, I killed all involved processes I could find in the mean time). Probably the solution will be a reboot. Systemd really brings us closer to the other "great" Desktop OS's.
timedatectl does not cause any misbehaviour here and well, NTPD is not integrated with timedatectl/timedated in 12.3 .. it does not have native units and does not have hooks into it, this is not a bug of systemd but on the ntp package.
Am 14.04.2013 02:15, schrieb Cristian Rodríguez:
El 13/04/13 20:34, Stefan Seyfried escribió:
That's not feasible as I need to enable debugging at boot and then have lots debug information wasting cycles just to debug the shutdown 2 weeks later once a new kernel is out. Or is there a way to enable debugging just before shutdown? I have not found one.
didnt this --> http://freedesktop.org/wiki/Software/systemd/Debugging help ?
Cite: "after booting with systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M"
I'm not very inclined towards running all productive systems with "sir spamalot" configuration to diagnose eventual shutdown problems.
I'll probably look into the debug shell.
Anyway -- debugging this with SysV init was a breeze compared with systemd.
are you sure the "freeze" is caused by systemd ? maybe be kernel bug..just saying...
Pretty sure. After several sysrq-E, "ctrl-alt-del", sysrq-E, waiting, more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of the time. Does not really look like a kernel problem to me.
My cryptohome does not mount every second boot. This time it was actually asking me for the password on the text console and echoing the passphrase to the terminal(!), but then at least it mounted $HOME.
I think I have reported cryptohome mount problems at least three times in bugzilla, but I'm just tired of it.
There were bugs, in the next iteration of systemd there are fixes included for that.
Yes, there have always been, in every iteration since I first tried systemd-30 or such. However, with SysV init my very same cryptohome has just worked for way longer than 10 years.
10 years from now, maybe it will even work with systemd.
Forwarding to syslog-ng does not work. Only "Forwarding to syslog missed XXX messages" all the time.
have you considered that might be a bug in syslog-ng units and nothing to do with systemd ?
Syslog worked very well before systemd / journal got forced down everyone's throats.
One thing I really hate about systemd is the total ignorance of both upstream and many of its downstream proponents (Frederic is explicitly excluded from this rant):
"we break everything *simply because we can*" "everybody else needs to clean up the mess we left"
The tipping point for me was the "break everybody's suspend keys config". Now I'm done with it.
Syslog worked before systemd. Then it broke (until yesterday, right now it seems to work but that might be typical nondeterministic systemd behaviour). IMNSVHO the ones who broke it should fix it. No, the finger is pointed at everybody else doing "broken" things -- funnily the same "broken" things have worked for ages before.
(and no, journal is not an
alternative, because the performance is abysmal. "journalctl", then hitting "end" thrashes my disk for about three minutes before responding. I can grep through 3 Years worth of /var/log/messages-* in the same time).
Since systemd 195 there have been a lot of improvements into the journal, I suggest you test and report what happends with systemd > 201
I doubt they will fix the online file format after the fact. The problem is, that it creates massively fragmented files on-disk and this hurts everyone with non-SSD setup. Probably it works well on Lennart and Kay's notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10 seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for too long.
Maybe it works for you, but for me it is an nondeterministic heap of crap. Latest example: Curiously after timedatectl was mentioned in this hread, I issued "timedatectl" as a nonprivileged user(!) to see what it would give me. Now I no longer can start / stop ntp and ntp is broken. WTF? (Yes, I killed all involved processes I could find in the mean time). Probably the solution will be a reboot. Systemd really brings us closer to the other "great" Desktop OS's.
timedatectl does not cause any misbehaviour here and well, NTPD is not integrated with timedatectl/timedated in 12.3
I'm running Factory, there it is even more broken apparently. (Yes, I know, Factory might contain new bugs, this is why I normally keep silent about all the systemd stuff. I joust could not stand the cheering systemd crowd anymore this time. I'll go back and just work around the issues for me now. Building a full featured current busybox right now).
.. it does not have native units and does not have hooks into it, this is not a bug of systemd but on the ntp package.
Yeah, but why do the systemd proponents not fix it? Why does everyone need to clean up after systemd?
El 14/04/13 06:09, Stefan Seyfried escribió:
Syslog worked before systemd. Then it broke (until yesterday, right now it seems to work but that might be typical nondeterministic systemd behaviour).
systemd is doing what is told, however what it is being told is wrong,apparently those who wrote the syslog openSUSE-custom units, did not RTFM.
Yeah, but why do the systemd proponents not fix it? Why does everyone need to clean up after systemd?
That's what we have been doing for a while, it is bummer than days only have 24 hours...
El 14/04/13 06:09, Stefan Seyfried escribió:
Anyway -- debugging this with SysV init was a breeze compared with systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging shell scripts.
Pretty sure. After several sysrq-E, "ctrl-alt-del", sysrq-E, waiting, more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of the time. Does not really look like a kernel problem to me.
If your machine has /dev/watchdog device you could also set RuntimeWatchdogSec=20s in /etc/systemd/system then the hardware will take care of rebooting the machine when things go bad.
However it will be cool to know why does it "freeze" at boot.
One thing I really hate about systemd is the total ignorance of both upstream.
Then you are not paying good attention, pretty much everything has or is landing in upstream projects in one way or another.
I doubt they will fix the online file format after the fact. The problem is, that it creates massively fragmented files on-disk and this hurts everyone with non-SSD setup. Probably it works well on Lennart and Kay's notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10 seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for too long.
Since I see you are using syslog..(and by your description of fact, the journal lives on a btrfs partition..does it?) can I suggest you a workaround in the meanwhile ? set Storage=volatile in /etc/systemd/journald.conf.
(maybe we should move the discussion to factory? anyway, I'd think we better let it die soon)
Am 14.04.2013 19:18, schrieb Cristian Rodríguez:
El 14/04/13 06:09, Stefan Seyfried escribió:
Anyway -- debugging this with SysV init was a breeze compared with systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging shell scripts.
Which is a breeze compared with debugging systemd. As systemd is PID 1, a single mistyped debug-printf in the code will panic my system. If I mistype something in an init script, I boot with init=/bin/bash and fix the typo.
Compared to "#!/bin/bash -x" in the old-style init scripts, it is much harder to debug systemd correctly.
Pretty sure. After several sysrq-E, "ctrl-alt-del", sysrq-E, waiting, more sysrq-E, some more ctrl-alt-del the system finally reboots. Most of the time. Does not really look like a kernel problem to me.
If your machine has /dev/watchdog device you could also set RuntimeWatchdogSec=20s in /etc/systemd/system then the hardware will take care of rebooting the machine when things go bad.
Actually I'd prefer to do sysrq-E, syrq-I, sysrq-S, sysrq-U before just rebooting it hard. Often enough, a few additional sysrq-E and ctrl-alt-del actally make sytemd reboot the system, but it takes way longer than the old "slow" sysV init... so much for fast booting, fast shutdown surely comes with the next version.
However it will be cool to know why does it "freeze" at boot.
One thing I really hate about systemd is the total ignorance of both upstream.
Then you are not paying good attention, pretty much everything has or is landing in upstream projects in one way or another.
I doubt they will fix the online file format after the fact. The problem is, that it creates massively fragmented files on-disk and this hurts everyone with non-SSD setup. Probably it works well on Lennart and Kay's notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10 seconds because it queries the journal.
And yeah -- again "the next version will fix it". I'm hearing this for too long.
Since I see you are using syslog..(and by your description of fact, the journal lives on a btrfs partition..does it?)
No. plain old ext4. I'm a bit conservative on my production machines.
can I suggest you a workaround in the meanwhile ? set Storage=volatile in /etc/systemd/journald.conf.
I'll do that once I gained some confidence that the working syslog is not an accident (means: it survives a few reboots).
Again with the journal, similar to systemd: the idea looks promising, but the implementation is painful.
El 14/04/13 14:58, Stefan Seyfried escribió:
(maybe we should move the discussion to factory? anyway, I'd think we better let it die soon)
Am 14.04.2013 19:18, schrieb Cristian Rodríguez:
El 14/04/13 06:09, Stefan Seyfried escribió:
Anyway -- debugging this with SysV init was a breeze compared with systemd.
No Stefan, it wasn't a breeze, it was a hack that required debugging shell scripts.
Which is a breeze compared with debugging systemd. As systemd is PID 1, a single mistyped debug-printf in the code will panic my system. If I mistype something in an init script, I boot with init=/bin/bash and fix the typo.
Compared to "#!/bin/bash -x" in the old-style init scripts, it is much harder to debug systemd correctly.
Myth 25 --> http://0pointer.de/blog/projects/the-biggest-myths.html
I'll do that once I gained some confidence that the working syslog is not an accident (means: it survives a few reboots).
If you applied the unit I sent you, ensure things are cool by issuing systemctl reenable syslog-ng.service too (missed that bit in the prev mail)
On Sun, Apr 14, 2013 at 6:09 AM, Stefan Seyfried stefan.seyfried@googlemail.com wrote:
(and no, journal is not an
alternative, because the performance is abysmal. "journalctl", then hitting "end" thrashes my disk for about three minutes before responding. I can grep through 3 Years worth of /var/log/messages-* in the same time).
Since systemd 195 there have been a lot of improvements into the journal, I suggest you test and report what happends with systemd > 201
I doubt they will fix the online file format after the fact. The problem is, that it creates massively fragmented files on-disk and this hurts everyone with non-SSD setup. Probably it works well on Lennart and Kay's notebooks with fast SSD but it sucks almost everywhere else.
Even each "systemctl status foo.service" thrashes the disk for ~10 seconds because it queries the journal.
This may have something to do with the fact that the journal is mmaped into memory, even for writing.
It may be worthwhile to consider a different strategy there, or at least make heavy use of madvise, in conjunction with preallocating the space on disk, to make sure the FS allocates it sequentially.
Otherwise, the result will be a sparse file, which are usually heavily fragmented when written in random order.
I guess I should say this upstream, but the thought occurred to me here, I hope Christian will push it upstream if it is worthwhile?
В Sun, 14 Apr 2013 01:34:53 +0200 Stefan Seyfried stefan.seyfried@googlemail.com пишет:
Am 14.04.2013 00:34, schrieb Cristian Rodríguez:
El 13/04/13 19:19, Stefan Seyfried escribió:
Nobody fixes systemd bugs is my observation. Only new ones are added all the time :-)
That's not true.
My machine has been unable to shut down without sysrq-E and sometimes sysrq-I. It hangs somewhere, but because everything is totally silent it does not show any debugging output.
did you enabled debugging ?
That's not feasible as I need to enable debugging at boot and then have lots debug information wasting cycles just to debug the shutdown 2 weeks later once a new kernel is out. Or is there a way to enable debugging just before shutdown? I have not found one.
SIGRTMIN+22, SIGRTMIN+23 Sets the log level to debug (or info on SIGRTMIN+23), as controlled via systemd.log_level=debug (or systemd.log_level=info on SIGRTMIN+23) on the kernel command line.
SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28, SIGRTMIN+29 Sets the log level to journal-or-kmsg (or console on SIGRTMIN+27,
You can list signals using "kill -l"; SIGRTMIN+22 is 56 here and SIGRTMIN+27 is 61. So
kill -56 1 kill -61 1 dmesg -n 7
Gives me debug output on console (I had to repeat "kill -61" for whatever reason, may be it takes time to switch).
Am 14.04.2013 07:33, schrieb Andrey Borzenkov:
В Sun, 14 Apr 2013 01:34:53 +0200 Stefan Seyfried stefan.seyfried@googlemail.com пишет:
That's not feasible as I need to enable debugging at boot and then have lots debug information wasting cycles just to debug the shutdown 2 weeks later once a new kernel is out. Or is there a way to enable debugging just before shutdown? I have not found one.
SIGRTMIN+22, SIGRTMIN+23 Sets the log level to debug (or info on SIGRTMIN+23), as controlled via systemd.log_level=debug (or systemd.log_level=info on SIGRTMIN+23) on the kernel command line. SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28, SIGRTMIN+29 Sets the log level to journal-or-kmsg (or console on SIGRTMIN+27,You can list signals using "kill -l"; SIGRTMIN+22 is 56 here and SIGRTMIN+27 is 61. So
kill -56 1 kill -61 1 dmesg -n 7
That's good to know. I would put this into before.local so that I don't forget it, but I'm pretty sure (have not tried) that this no longer works with systemd.
Thanks, this might help when the next kernel comes out.
В Sat, 13 Apr 2013 19:34:44 -0300 Cristian Rodríguez crrodriguez@opensuse.org пишет:
My machine has been unable to shut down without sysrq-E and sometimes sysrq-I. It hangs somewhere, but because everything is totally silent it does not show any debugging output.
did you enabled debugging ?
Did you actually try to debug problems that happen on shutdown due to incorrect unit dependencies? systemd simply does not provide enough information so it is more of a black magic than science. You just see that something is timed out. You never see *why* it timed out (i.e. what unit it had been waiting on).
This had been this way 3 years ago, this remains this way today. As far as I can tell this is due to design of systemd so I am not sure if it is even possible to ever fix it.
On Sun, Apr 14, 2013 at 09:40:28AM +0400, Andrey Borzenkov wrote:
Did you actually try to debug problems that happen on shutdown due to incorrect unit dependencies? systemd simply does not provide enough information so it is more of a black magic than science. You just see that something is timed out. You never see *why* it timed out (i.e. what unit it had been waiting on).
This had been this way 3 years ago, this remains this way today. As far as I can tell this is due to design of systemd so I am not sure if it is even possible to ever fix it.
Latest systemd will tell you what timed out.
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
[Unit] Description=System Logging Service Requires=var-run.mount Requires=syslog.socket After=var-run.mount Conflicts=rsyslog.service syslogd.service
[Service] Environment=SYSLOG_NG_PARAMS= ExecStartPre=/usr/sbin/syslog-ng-service-prepare EnvironmentFile=-/etc/sysconfig/syslog ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS ExecReload=/bin/kill -HUP $MAINPID StandardOutput=null
[Install] WantedBy=multi-user.target Alias=syslog.service
systemctl --system daemon-reload
test, test, test..
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
[Unit] Description=System Logging Service Requires=var-run.mount Requires=syslog.socket After=var-run.mount Conflicts=rsyslog.service syslogd.service
[Service] Environment=SYSLOG_NG_PARAMS= ExecStartPre=/usr/sbin/syslog-ng-service-prepare EnvironmentFile=-/etc/sysconfig/syslog ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS ExecReload=/bin/kill -HUP $MAINPID StandardOutput=null
[Install] WantedBy=multi-user.target Alias=syslog.service
systemctl --system daemon-reload
test, test, test..
Ok, changed this, next reboot date depends on Kernel:HEAD having x86_64 relevant updates
I found that /etc/systemd/system contains lots of directories and symlinks that do not belong to any package. And then there is one file that also does not belong to any package:
systemd-random-seed-load.service
it's dated Jan 29 2013, I'm pretty sure I did not create it manually and it fails.
To get back on topic in opensuse-packaging:
should we mark all those /etc/systemd/system/dbus-org.bluez.service and friends as %ghost in the packages so that one actually can find out if this is a system file or not? I'm usually inclined to remove everything not known to RPM from my systems, but I figured that this might break my system even more.... :-)
On Sun, 14 Apr 2013 11:29, Stefan Seyfried <stefan.seyfried@...> wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
[snip]
I found that /etc/systemd/system contains lots of directories and symlinks that do not belong to any package. And then there is one file that also does not belong to any package:
systemd-random-seed-load.service
it's dated Jan 29 2013, I'm pretty sure I did not create it manually and it fails.
To get back on topic in opensuse-packaging:
should we mark all those /etc/systemd/system/dbus-org.bluez.service and friends as %ghost in the packages so that one actually can find out if this is a system file or not? I'm usually inclined to remove everything not known to RPM from my systems, but I figured that this might break my system even more.... :-)
With these symlinks under /etc/systemd/.. does systemd the control what to start (and what target wants which service / socket), similar to /etc/init.d/rc?.d/[SK][num][name] symlinks from sysVinit.
The service / socket / target files themself reside under /lib/systemd/... and / or /usr/lib/systemd/... so, if you have a candidate like "systemd-random-seed-load.service" from above, use locate / or find -name
on those two "lib" dirs, for the file shown this should give: /usr/lib/systemd/system/sysinit.target.wants/systemd-random-seed-load.service /usr/lib/systemd/system/systemd-random-seed-load.service
and a man-page: /usr/share/man/man8/systemd-random-seed-load.service.8.gz
a "rpm -qf" on those makes more sense than on the /etc/ symlinks. (and shows that this file belongs to the systemd package)
But imho it's a learn-everything-anew thing with systemd, esp. debugging faults is not so easy any more.
For example:
But a nonvalid line in your syslog-ng / rsyslog config and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
A "systemctl status syslog.service" gives just a "failed" but not the error message from the deamon itself. And systemd tries to spawn syslog.service contiously anew.
Happy debugging.
A question to the ones that do the config defaults for rsyslogd : why are the cron messages in the /var/log/NetworkManager file? (OSS 12.3 out of the box)
I'm still at the start of learning how to handle systemd.
For added praxis I try writing .service files for deamons that I use and that do not bring them in the package.
That can be very frustrating, due to the lack of useable debug output.
And then we can start about determinability. Or the lack of.
- Yamaban, who wishes you all a nice weekend.
On 14/4/2013 at 03:52 PM, Yamaban foerster@lisas.de wrote:
On Sun, 14 Apr 2013 11:29, Stefan Seyfried <stefan.seyfried@...> wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
[snip]
I found that /etc/systemd/system contains lots of directories and symlinks that do not belong to any package. And then there is one file that also does not belong to any package:
systemd-random-seed-load.service
<snip>>
For example:
But a nonvalid line in your syslog-ng / rsyslog config and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
journalctl [-b]
Refer to journalctl man page to view logs of a specific unit or other uses.
Srinidhi.
В Sun, 14 Apr 2013 04:58:01 -0600 "Srinidhi B" srinidhi@novell.com пишет:
On 14/4/2013 at 03:52 PM, Yamaban foerster@lisas.de wrote:
On Sun, 14 Apr 2013 11:29, Stefan Seyfried <stefan.seyfried@...> wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
[snip]
I found that /etc/systemd/system contains lots of directories and symlinks that do not belong to any package. And then there is one file that also does not belong to any package:
systemd-random-seed-load.service
<snip>>
For example:
But a nonvalid line in your syslog-ng / rsyslog config and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
journalctl [-b]
Refer to journalctl man page to view logs of a specific unit or other uses.
You miss the point. systemd silently ignores error and pretends unit file is OK. There is no reason to dig into journal because no error is reported in the first place.
bor@opensuse:~> sudo systemctl status foo.service foo.service - Test foo Loaded: loaded (/run/systemd/system/foo.service; static) Active: inactive (dead) CGroup: name=systemd:/system/foo.service
bor@opensuse:~> sudo systemctl show -p Type foo.service Type=simple bor@opensuse:~> grep Type /run/systemd/system/foo.service Type=xxxx
See? It ignored invalid value for Type and silently replaced it with something else. Yes, you will see it in journal, but admin has no reason to look there in the first place - everything appears to be OK.
El 14/04/13 08:20, Andrey Borzenkov escribió:
See? It ignored invalid value for Type and silently replaced it with something else. Yes, you will see it in journal, but admin has no reason to look there in the first place - everything appears to be OK.
Hrmm..you might have a point here..
if (!empty(type) || !is_valid_type(type)) then it should mark the unit as failed... empty means "simple"..
On Sun, Apr 14, 2013 at 2:22 PM, Yamaban foerster@lisas.de wrote:
But imho it's a learn-everything-anew thing with systemd, esp. debugging faults is not so easy any more.
For example:
But a nonvalid line in your syslog-ng / rsyslog config and do a "systemctl reload syslog.service" .
Just where are your "Fail / Error" messages? - Not nice.
A "systemctl status syslog.service" gives just a "failed" but not the error message from the deamon itself. And systemd tries to spawn syslog.service contiously anew.
Happy debugging.
Could you test if this commit does what you want?
http://cgit.freedesktop.org/systemd/systemd/commit/?id=e8e581bf256b8c0fbd430...
El 14/04/13 06:29, Stefan Seyfried escribió:
I found that /etc/systemd/system contains lots of directories and symlinks that do not belong to any package.
That's correct, nothing there belongs to any package, expected.
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
[Unit] Description=System Logging Service Requires=var-run.mount Requires=syslog.socket After=var-run.mount Conflicts=rsyslog.service syslogd.service
[Service] Environment=SYSLOG_NG_PARAMS= ExecStartPre=/usr/sbin/syslog-ng-service-prepare EnvironmentFile=-/etc/sysconfig/syslog ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS ExecReload=/bin/kill -HUP $MAINPID StandardOutput=null
[Install] WantedBy=multi-user.target Alias=syslog.service
rebooted today,
susi:~ # journalctl -b | grep Forwarding Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112 messages. Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31 messages.
Before: Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog Socket. Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Listening on Syslog Socket. ... Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Started Journal Service. Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog. Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Reached target Syslog.
susi:~ # ps xauwww|grep syslog-ng root 1022 0.0 0.0 211028 4196 ? Ssl 08:46 0:00 /usr/sbin/syslog-ng -F susi:~ # stat /proc/1022/ File: ‘/proc/1022/’ Size: 0 Blocks: 0 IO Block: 1024 directory Device: 3h/3d Inode: 14613 Links: 8 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-04-17 08:46:09.932639720 +0200 Modify: 2013-04-17 08:46:09.932639720 +0200 Change: 2013-04-17 08:46:09.932639720 +0200 Birth: -
So it looks like syslog-ng is only started after the first "Forwarding to syslog missed..." message.
But I can tolerate this if it now keeps logging for longer than a few days (I rebooted because it again stopped doing that and apparently the only way to get things to work reliably with systemd is to reboot, at least if you don't want to do a PhD thesis on "booting linux" but just work with the box).
I understand correctly: there is no way to get rid of journal completely and just log to syslog like we always did (or passing the messages from syslog to journal instead of the other, non-working way round)? Would it be possible to let the journal only handle systemd but keep away from the tradiditonal syslog socket?
On Wed, Apr 17, 2013 at 12:28 PM, Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
Does not it also need "systemctl enable syslog-ng.service", so that ...
[Unit] Description=System Logging Service Requires=var-run.mount Requires=syslog.socket After=var-run.mount Conflicts=rsyslog.service syslogd.service
[Service] Environment=SYSLOG_NG_PARAMS= ExecStartPre=/usr/sbin/syslog-ng-service-prepare EnvironmentFile=-/etc/sysconfig/syslog ExecStart=/usr/sbin/syslog-ng -F $SYSLOG_NG_PARAMS ExecReload=/bin/kill -HUP $MAINPID StandardOutput=null
[Install] WantedBy=multi-user.target Alias=syslog.service
... alias syslog.service is correctly created?
rebooted today,
susi:~ # journalctl -b | grep Forwarding Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112 messages. Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31 messages.
Before: Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog Socket. Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Listening on Syslog Socket. ... Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Started Journal Service. Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Starting Syslog. Apr 17 08:45:41 susi.home.s3e.de systemd[1]: Reached target Syslog.
susi:~ # ps xauwww|grep syslog-ng root 1022 0.0 0.0 211028 4196 ? Ssl 08:46 0:00 /usr/sbin/syslog-ng -F susi:~ # stat /proc/1022/ File: ‘/proc/1022/’ Size: 0 Blocks: 0 IO Block: 1024 directory Device: 3h/3d Inode: 14613 Links: 8 Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2013-04-17 08:46:09.932639720 +0200 Modify: 2013-04-17 08:46:09.932639720 +0200 Change: 2013-04-17 08:46:09.932639720 +0200 Birth: -
So it looks like syslog-ng is only started after the first "Forwarding to syslog missed..." message.
Yes, it tries to start syslog.service when something connects to syslog socket. What "systemctl status syslog.service" show?
But I can tolerate this if it now keeps logging for longer than a few days (I rebooted because it again stopped doing that and apparently the only way to get things to work reliably with systemd is to reboot, at least if you don't want to do a PhD thesis on "booting linux" but just work with the box).
I understand correctly: there is no way to get rid of journal completely and just log to syslog like we always did (or passing the messages from syslog to journal instead of the other, non-working way round)? Would it be possible to let the journal only handle systemd but keep away from the tradiditonal syslog socket?
OK, but let's face it - before journald these messages were silently lost. Now you are at least aware of this and optionally can also collect and store them persistently. Why getting messages is worse than losing them?
On 04/17/2013 06:01 AM, Andrey Borzenkov wrote:
On Wed, Apr 17, 2013 at 12:28 PM, Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Am 14.04.2013 02:55, schrieb Cristian Rodríguez:
Ok Stefan:
So your syslog-ng losses messages on boot.. can you please test the following unit file and report back ?
save it as "syslog-ng.service" in /etc/systemd/system/
Does not it also need "systemctl enable syslog-ng.service", so that ...
yep.
... alias syslog.service is correctly created?
It should be on systemctl reenable...
OK, but let's face it - before journald these messages were silently lost. Now you are at least aware of this and optionally can also collect and store them persistently. Why getting messages is worse than losing them?
Im also a little bit annoyed by this, because I fail to see what exactly is his complain now, first it was because messages were lost, now it is because messages are beign forwarded huh wth?
Am 17.04.2013 11:01, schrieb Andrey Borzenkov:
OK, but let's face it - before journald these messages were silently lost. Now you are at least aware of this and optionally can also collect and store them persistently. Why getting messages is worse than losing them?
I don't care too much about not forwarding the boot messages, as long as the journal does not stop forwarding after some random time (a few days). That is really pissing me off.
(And no, "the journal has them stored also" is not an answer. It is too slow and I cannot grep through those logs with my known-working tools).
El 17/04/13 12:41, Stefan Seyfried escribió:
I don't care too much about not forwarding the boot messages, as long as the journal does not stop forwarding after some random time (a few days). That is really pissing me off.
Does it stop forwarding after days ? why you did not mentioned this ?
(And no, "the journal has them stored also" is not an answer. It is too slow
Your disk is slow.. ;)
and I cannot grep through those logs with my known-working tools).
There is no need for grep in this case..
Am 17.04.2013 17:45, schrieb Cristian Rodríguez:
El 17/04/13 12:41, Stefan Seyfried escribió:
I don't care too much about not forwarding the boot messages, as long as the journal does not stop forwarding after some random time (a few days). That is really pissing me off.
Does it stop forwarding after days ? why you did not mentioned this ?
This was my complaint from the beginning. The drop at boot was just an additional detail.
El 17/04/13 12:49, Stefan Seyfried escribió:
This was my complaint from the beginning.
OK, I dont think that we could solve either a bug or confussion here, please open a report about this.
I don't care too much about not forwarding the boot messages, as long as the journal does not stop forwarding after some random time (a few days). That is really pissing me off.
With the new units, syslog implementations *require* the syslog socket, if that goes away for whatever reason, the service will fail and you will know why ...
On 04/17/2013 05:28 AM, Stefan Seyfried wrote:
susi:~ # journalctl -b | grep Forwarding Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112 messages. Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31 messages.
This is correct, it is operating exactly as intended.
So it looks like syslog-ng is only started after the first "Forwarding to syslog missed..." message.
Yes, nothing wrong with that, what do you expect ? no messages "lost", as the log says the journal forwarded messages to syslog when it started, syslog is a regular service, it has to start waay *after* systemd begins logging..
I understand correctly: there is no way to get rid of journal completely and just log to syslog like we always did (or passing the messages from syslog to journal instead of the other, non-working way round)? Would it be possible to let the journal only handle systemd but keep away from the tradiditonal syslog socket?
No, and there is nothing wrong in what it is currently doing, care to explain exactly what you see it is wrong now ?
El 17/04/13 11:51, Cristian Rodríguez escribió:
On 04/17/2013 05:28 AM, Stefan Seyfried wrote:
susi:~ # journalctl -b | grep Forwarding Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112 messages. Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31 messages.
This is correct, it is operating exactly as intended.
So it looks like syslog-ng is only started after the first "Forwarding to syslog missed..." message.
Yes, nothing wrong with that, what do you expect ? no messages "lost", as the log says the journal forwarded messages to syslog when it started, syslog is a regular service, it has to start waay *after* systemd begins logging..
Messages told to be "missed" are stored in the journal (in the past, when syslog was the only way, those messages were simply lost) in this context "missed" means that the syslog socket buffer is full and can't take it anymore.
Am 17.04.2013 17:31, schrieb Cristian Rodríguez:
El 17/04/13 11:51, Cristian Rodríguez escribió:
On 04/17/2013 05:28 AM, Stefan Seyfried wrote:
susi:~ # journalctl -b | grep Forwarding Apr 17 08:46:05 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 112 messages. Apr 17 08:46:46 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 31 messages.
This is correct, it is operating exactly as intended.
So it looks like syslog-ng is only started after the first "Forwarding to syslog missed..." message.
Ok, that's fine.
Yes, nothing wrong with that, what do you expect ? no messages "lost", as the log says the journal forwarded messages to syslog when it started, syslog is a regular service, it has to start waay *after* systemd begins logging..
Messages told to be "missed" are stored in the journal (in the past, when syslog was the only way, those messages were simply lost) in this context "missed" means that the syslog socket buffer is full and can't take it anymore.
Well, the syslog buffer never was full and dropping messages after a few days of uptime before journal came along.
This is not about a 100k messages / second syslog server, this is a notebook with 3 dhclient messages every 30 minutes and all of them get lost once it starts to malfunction.
I will see if it works better now after the reboot.
And voila: last message in syslog is
Apr 17 14:28:55 susi dhclient[1923]: DHCPREQUEST on air to ...
and journal starts dropping at...
Apr 17 14:31:07 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 1 messages.
Everything after that is missing from syslog.
=> journald does not work as advertised. Can I prevent systemd/journald's occupation of the syslog socket somehow?
El 17/04/13 12:47, Stefan Seyfried escribió:
And voila: last message in syslog is
Apr 17 14:28:55 susi dhclient[1923]: DHCPREQUEST on air to ...
Apr 17 14:31:07 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 1 messages. Everything after that is missing from syslog.
What do you mean ? You are not expressing your problem correctly I am afraid
=> journald does not work as advertised.
WHAT? it does work as expected, unless your expectatives are different or distorted..
Can I prevent
systemd/journald's occupation of the syslog socket somehow?
No, This is a mandatory feature.
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
And voila: last message in syslog is
Apr 17 14:28:55 susi dhclient[1923]: DHCPREQUEST on air to ...
Apr 17 14:31:07 susi.home.s3e.de systemd-journal[249]: Forwarding to syslog missed 1 messages. Everything after that is missing from syslog.
What do you mean ? You are not expressing your problem correctly I am afraid
Isn't that obvious? After the DHCPREQUEST entry there should be more entries following. There aren't, so they are missing. Stefan complains about that. Correctly so.
=> journald does not work as advertised.
WHAT? it does work as expected,
huh? It surely isn't expected to stop forwarding messages to syslog once there was an error in transmission (which is also highly unlikely to occur, certainly syslog buffers aren't full because of one DHCP syslog entry).
unless your expectatives are different or distorted..
If you could stop being obnoxious I would be thankful.
Can I prevent systemd/journald's occupation of the syslog socket somehow?
No, This is a mandatory feature.
Then it better be fixed, right?
Ciao, Michael.
El mié 17 abr 2013 13:04:17 CLST, Michael Matz escribió:
Isn't that obvious? After the DHCPREQUEST entry there should be more entries following. There aren't, so they are missing. Stefan complains about that. Correctly so.
OK, then does the journal have the entries then ?
huh? It surely isn't expected to stop forwarding messages to syslog once there was an error in transmission (which is also highly unlikely to occur, certainly syslog buffers aren't full because of one DHCP syslog entry).
It does not stop forwarding when there is an error ..
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
El mié 17 abr 2013 13:04:17 CLST, Michael Matz escribió:
Isn't that obvious? After the DHCPREQUEST entry there should be more entries following. There aren't, so they are missing. Stefan complains about that. Correctly so.
OK, then does the journal have the entries then ?
huh? It surely isn't expected to stop forwarding messages to syslog once there was an error in transmission (which is also highly unlikely to occur, certainly syslog buffers aren't full because of one DHCP syslog entry).
It does not stop forwarding when there is an error ..
That we know only after debugging. The symptoms look like so, and that's what Stefan reported.
Ciao, Michael.
Am 17.04.2013 18:12, schrieb Michael Matz:
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
It does not stop forwarding when there is an error ..
That we know only after debugging. The symptoms look like so, and that's what Stefan reported.
Let's end the thread.
Cristian is probably right, systemd is probably not to blame.
It looks like a syslog-ng bug, it apparently soft-locks around a g_static_mutex_lock(&self->lock);
https://bugzilla.novell.com/815746
Followup-to: opensuse-factory.
Sorry for the noise, I should have explored this way earlier (But since syslog-ng has been reliable for me for the last >5 years, it did not come to my mind...)
Best regards and thanks for all the offered help, now I have at least a cheat-sheet for what to enable during shutdown to debug systemd shutdown hangs :-)
Stefan
El mié 17 abr 2013 14:51:45 CLST, Stefan Seyfried escribió:
Am 17.04.2013 18:12, schrieb Michael Matz:
Hi,
On Wed, 17 Apr 2013, Cristian Rodríguez wrote:
It does not stop forwarding when there is an error ..
That we know only after debugging. The symptoms look like so, and that's what Stefan reported.
Let's end the thread.
Cristian is probably right, systemd is probably not to blame.
It looks like a syslog-ng bug, it apparently soft-locks around a g_static_mutex_lock(&self->lock);
heh :-) anyway, the units required adjustment because there weren't quite right either.
Sorry for the noise, I should have explored this way earlier (But since syslog-ng has been reliable for me for the last >5 years, it did not come to my mind...)
No, thank YOU for looking for the root cause ;)
On Thursday, April 04, 2013 08:23:10 Michal Kubeček wrote:
On Wednesday 03 of April 2013 20:20EN, Andreas Jaeger wrote:
But if a package is not build for SLE 11, then why should it have an init file?
Because OpenSuSE is supposed to be a codebase for SLE12. And I don't see much sense in taking effort in carefully removing anything reminding System V init now and then making it work with System V init again several months later (yes, perhaps I'm naïve, but I still believe there will be System V init in SLE12).
Michal, SLE 12 will have systemd,
Andreas
On Thursday 04 of April 2013 09:13EN, Andreas Jaeger wrote:
Michal, SLE 12 will have systemd,
Yes, I'm sure this is inevitable. But this doesn't mean it cannot have System V init.
Michal Kubeček
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
But this doesn't mean it cannot have
System V init.
For all practical reasons, yes it means it cannot.
On Thu, Apr 04, 2013 at 04:34:04AM -0300, Cristian Rodríguez wrote:
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
But this doesn't mean it cannot have
System V init.
For all practical reasons, yes it means it cannot.
Well the compat mode for 3rd party init scripts will work, but not much more.
Btw, do not blindly remove sysvinit scripts from packages that are also built and used on older distributions, e.g. dnsmasq.
Ciao, Marcus
On Thu 04 Apr 2013 04:53:46 AM CLST, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 04:34:04AM -0300, Cristian Rodríguez wrote:
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
But this doesn't mean it cannot have
System V init.
For all practical reasons, yes it means it cannot.
Well the compat mode for 3rd party init scripts will work, but not much more.
Btw, do not blindly remove sysvinit scripts from packages that are also built and used on older distributions, e.g. dnsmasq.
Package fails to build in old distros with or without the change.. did you saw the build status ?
On Thu, Apr 04, 2013 at 05:02:55AM -0300, Cristian Rodríguez wrote:
On Thu 04 Apr 2013 04:53:46 AM CLST, Marcus Meissner wrote:
On Thu, Apr 04, 2013 at 04:34:04AM -0300, Cristian Rodríguez wrote:
On 04/04/2013 04:23 AM, Michal Kubeček wrote:
But this doesn't mean it cannot have
System V init.
For all practical reasons, yes it means it cannot.
Well the compat mode for 3rd party init scripts will work, but not much more.
Btw, do not blindly remove sysvinit scripts from packages that are also built and used on older distributions, e.g. dnsmasq.
Package fails to build in old distros with or without the change.. did you saw the build status ?
hmm, it had fails in your project, but i see that network disables it mostly.
Ciao, Marcus
On 04/03/2013 11:42 AM, Yamaban wrote:
As long as there is a SLE(S|D) without systemd support you are shooting your own legs if you just "drop" all replaced sysVinit scripts.
SLE codebase has nothing to do with this.. SLE11 does not change unless there is a security update or a service pack, which has very specfic, delimited scope.
For systems with full systemd support (12.1 and later), install the scrips as %doc in the docdir for reference (and help).
init scripts are not documentation.
Before a drop could be considered (13.1 and following), there is more maturing needed (intoduce a .service, and get it working without troubles for a full release, e.g. a 'new' .service in 12.3 gets a moved /etc/init.d/ script as %doc in 13.1 and so on.
sounds like an entangled mess..will make things worst, not better.
Are you trying to get the SLE support crew mad at you?
I dont give a flying f** about who gets mad. ;D
Yamaban wrote:
On Wed, 3 Apr 2013 09:20, Ludwig Nussel <ludwig.nussel@...> wrote:
Stephan Kulow wrote:
On 02.04.2013 10:06, Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
We agreed not to enforce that. So your fine to have a package with init scripts. But it's perfectly fine also to have a rpmlint warning that a package has *only* init script and Cristian adding systemd services for them - if the maintainer of the package disagrees to add it, then we can talk again.
Well, the truth is that it doesn't make much sense anymore to keep the sysv scripts if there is a service file. It only adds potential code duplication and confusion. So I'd vote for having either .service files or init scripts in a package but not both. However, adding service files that break previous features or just add the init script shell code 1:1 as ExecStartPre should be avoided too.
As long as there is a SLE(S|D) without systemd support you are shooting your own legs if you just "drop" all replaced sysVinit scripts.
When I said 'keep the sysv scripts' I was referring to having them installed in the system if %suse_version >= 1230. The package maintainer is free to keep the scripts in the package sources and install them only if the package is used as backport of course.
cu Ludwig
On 04/05/2013 12:49 PM, Ludwig Nussel wrote:
When I said 'keep the sysv scripts' I was referring to having them installed in the system if %suse_version >= 1230. The package maintainer is free to keep the scripts in the package sources and install them only if the package is used as backport of course.
If there are both systemd.service and sysvinit file present my understanding was if %suse_version >= 1230 then only systemd service file and if %suse_version < 1230 then upto the packager but better to include sysvinit in this case
Am I missing it Togan
On Tuesday, April 02, 2013 10:06:46 Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
You don't need to make it an error,
Andreas
Le mardi 02 avril 2013 à 10:27 +0200, Andreas Jaeger a écrit :
On Tuesday, April 02, 2013 10:06:46 Michal Kubecek wrote:
On Fri, Mar 29, 2013 at 11:29:22PM -0300, Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so I can take look at them ? there is no rpmlint check for that :-|
And not long ago I was being assured there won't be...
You don't need to make it an error,
The only case where it should be an error is "early boot" initscripts (the one named boot.*). Support for that has been removed in upstream systemd and I'd prefer to not backport the support in our systemd, if we can avoid it..
El 02/04/13 06:05, Frederic Crozat escribió: Support for that has been removed in upstream
systemd and I'd prefer to not backport the support in our systemd, if we can avoid it..
As far as I understand, all those boot.* scripts that are not already masked, are replaced by upstream provided integration with systemd and dracut.
We should just drop them and integrate upstream changes, however this also implies getting rid of suse mkinitrd.
Le mardi 02 avril 2013 à 14:02 -0300, Cristian Rodríguez a écrit :
El 02/04/13 06:05, Frederic Crozat escribió: Support for that has been removed in upstream
systemd and I'd prefer to not backport the support in our systemd, if we can avoid it..
As far as I understand, all those boot.* scripts that are not already masked, are replaced by upstream provided integration with systemd and dracut.
We should just drop them and integrate upstream changes, however this also implies getting rid of suse mkinitrd.
Well, I would still like to see dracut replacing mkinitrd..
Hello,
Am Dienstag, 2. April 2013 schrieb Frederic Crozat:
Le mardi 02 avril 2013 à 10:27 +0200, Andreas Jaeger a écrit :
On Tuesday, April 02, 2013 10:06:46 Michal Kubecek wrote:
On Fri, Mar 29, 2013 Cristian Rodríguez wrote:
Does anyone have access to a full unpacked tree of factory and can post what packages contain init scripts but not service files so can take look at them ? there is no rpmlint check for that :-|
grepping ARCHIVES.gz might be helpful ;-)
(and it might be helpful to have an ARCHIVES.gz for factory)
The only case where it should be an error is "early boot" initscripts (the one named boot.*). Support for that has been removed in upstream systemd
Nice[tm]. What's the reason for this? (I assume "let's break some initscripts from stone age" was not the reason - I seriously hope Lennart is not evil enough for that ;-)
and I'd prefer to not backport the support in our systemd, if we can avoid it..
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
I'll give you a short overview from my system (Factory, last updated about 3 weeks ago):
# cd /etc/init.d && for file in boot.* ; do echo === $file ===; pac=$(rpm -qf $file); echo Package: $pac; rpm -ql $pac |grep '.service$'; echo; done
=== boot.apparmor === Package: apparmor-parser-2.8.1-130.1.x86_64
=== boot.cycle === Package: bootcycle-0.3-244.1.x86_64
=== boot.d === Package: filesystem-12.3-11.1.x86_64
=== boot.device-mapper === Package: device-mapper-1.02.77-22.1.x86_64
=== boot.dmraid === Package: dmraid-1.0.0.rc16-23.1.x86_64
=== boot.kdump === Package: kdump-0.8.1-21.1.x86_64
=== boot.loadmodules === Package: mkinitrd-2.7.2-5.7.x86_64 /usr/lib/systemd/system/purge-kernels.service # doesn't count ;-)
=== boot.local === Package: file /etc/init.d/boot.local is not owned by any package # but should continue to work ;-)
=== boot.localnet === Package: aaa_base-12.3-17.1.x86_64
=== boot.lvm === Package: lvm2-2.02.98-22.1.x86_64
=== boot.md === Package: mdadm-3.2.6-0.x86_64
=== boot.scpm === Package: scpm-1.1.7-21.1.x86_64
=== boot.sysstat === Package: sysstat-10.0.5-7.1.x86_64 /usr/lib/systemd/system/sysstat.service
=== boot.udev === Package: udev-195-24.1.x86_64 /usr/lib/systemd/system/basic.target.wants/systemd-udev-root-symlink.service /usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service /usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service /usr/lib/systemd/system/systemd-udev-root-symlink.service /usr/lib/systemd/system/systemd-udev-settle.service /usr/lib/systemd/system/systemd-udev-trigger.service /usr/lib/systemd/system/systemd-udevd.service /usr/lib/systemd/system/udev.service
In other words: from the 14 packages owning boot.* initscripts on my system, only 2 have service files.
I'm sure the maintainers of the other 12 will happily accept submit requests that add the service file and do the migration in %post ;-)
Note that I didn't write anything about "remove the initscript" - for AppArmor, I'd like to keep it for backwards compability with older openSUSE releases. Other maintainers might or might not have similar wishes.
BTW: is ExecStatus supported in the meantime?
(Needless to say that updating systemd is a no-go until all affected packages have a service file.)
Regards,
Christian Boltz
El 02/04/13 16:09, Christian Boltz escribió:
Nice[tm]. What's the reason for this? (I assume "let's break some initscripts from stone age" was not the reason - I seriously hope Lennart is not evil enough for that ;-)
Early boot scripts were a distribution specific extension of sysvinit, hence everybody does it differently.
To be more specific than Frederic, systemd no longer includes any distribution-specific code, all distributions targets (in our case TARGET_SUSE) are gone.
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
# cd /etc/init.d && for file in boot.* ; do echo === $file ===; pac=$(rpm -qf $file); echo Package: $pac; rpm -ql $pac |grep '.service$'; echo; done
=== boot.cycle === Package: bootcycle-0.3-244.1.x86_64
Not sure if that still works, the package consist of just an init script and instructions for GRUB legacy that is no longer even installed by default..
=== boot.d === Package: filesystem-12.3-11.1.x86_64
Unused.
=== boot.device-mapper === Package: device-mapper-1.02.77-22.1.x86_64
=== boot.dmraid === Package: dmraid-1.0.0.rc16-23.1.x86_64
Supported with systemd/dracut
=== boot.kdump === Package: kdump-0.8.1-21.1.x86_64
=== boot.loadmodules ===
Already sent a patch to replace it.
http://lists.opensuse.org/opensuse-kernel/2013-03/msg00016.html
Not merged yet :-( another reason to use dracut.
Package: mkinitrd-2.7.2-5.7.x86_64 /usr/lib/systemd/system/purge-kernels.service # doesn't count ;-)
=== boot.local === Package: file /etc/init.d/boot.local is not owned by any package # but should continue to work ;-)
Could replace that by a generator, or just call it "local.service".. ;)
=== boot.localnet === Package: aaa_base-12.3-17.1.x86_64
masked, I already sent a patch to remove it which was merged.
=== boot.lvm === Package: lvm2-2.02.98-22.1.x86_64
=== boot.md === Package: mdadm-3.2.6-0.x86_64
Supported with systemd/dracut.
=== boot.scpm === Package: scpm-1.1.7-21.1.x86_64
No idea.
=== boot.sysstat === Package: sysstat-10.0.5-7.1.x86_64 /usr/lib/systemd/system/sysstat.service
already migrated.
=== boot.udev ===
Unused,
Note that I didn't write anything about "remove the initscript" - for AppArmor, I'd like to keep it for backwards compability with older openSUSE releases. Other maintainers might or might not have similar wishes.
BTW: is ExecStatus supported in the meantime?
selinux and smack LSMs have native support merged in systemd (by the authors, Redhat and people from Intel respectively) kinda telling that apparmor doesn't...:-|
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
cu Ludwig
On 03.04.2013 09:26, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut yesterday.
Greetings, Stephan
On Wed, Apr 3, 2013 at 11:35 AM, Stephan Kulow coolo@suse.de wrote:
On 03.04.2013 09:26, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut yesterday.
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut? In case of dracut I'd tentatively volunteer to (co-)maintain it.
Le mercredi 03 avril 2013 à 12:13 +0400, Andrey Borzenkov a écrit :
On Wed, Apr 3, 2013 at 11:35 AM, Stephan Kulow coolo@suse.de wrote:
On 03.04.2013 09:26, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut yesterday.
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut? In case of dracut I'd tentatively volunteer to (co-)maintain it.
For mkinitrd (both package and sources).
On Wednesday 03 April 2013 12:13:50 Andrey Borzenkov wrote:
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut yesterday.
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut? In case of dracut I'd tentatively volunteer to (co-)maintain it.
Hi Andrey,
As Frederic already indicated mkinitrd seems to be the one missing the maintainership. However we would welcome any help we can get to really exploit dracut and to have it replace mkinitrd in openSUSE 13.1.
The main devel package is in the Base:System repository and currently Christian Rodriguez and I are maintaining it. A couple of months ago I took it upon me to get dracut into openSUSE, but unfortunately due to an work overload at my normal job, I am not able to spend that much time on it.
We are tracking the releases and the package is in openSUSE Factory. I guess the main thing to do is to validate if all angles are covered when using dracut to generate the inird instead of mkinitrd. This would be specifically with LUKS/crypt support.
Another topic would be not to increase the size of the initrd and to get the right default settings for dracut. These can then be integrated in the other packages that are currently calling mkinitrd.
So still some work to do, but in general things should work out-of-the-box.
Regards
Raymond
On Wed, Apr 3, 2013 at 4:34 AM, Raymond Wooninck tittiatcoke@gmail.com wrote:
On Wednesday 03 April 2013 12:13:50 Andrey Borzenkov wrote:
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut yesterday.
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut? In case of dracut I'd tentatively volunteer to (co-)maintain it.
Hi Andrey,
As Frederic already indicated mkinitrd seems to be the one missing the maintainership. However we would welcome any help we can get to really exploit dracut and to have it replace mkinitrd in openSUSE 13.1.
The main devel package is in the Base:System repository and currently Christian Rodriguez and I are maintaining it. A couple of months ago I took it upon me to get dracut into openSUSE, but unfortunately due to an work overload at my normal job, I am not able to spend that much time on it.
We are tracking the releases and the package is in openSUSE Factory. I guess the main thing to do is to validate if all angles are covered when using dracut to generate the inird instead of mkinitrd. This would be specifically with LUKS/crypt support.
I use LUKS for root and - while it took me a few tries - I do have a working system that boots just fine with either dracut or mkinitrd-built initrds. The key for me was that I had to refer to the (very good!) Fedora documentation to add: rd.auto to the kernel/initrd commandline. I still can't get dracut to decrypt my swap partition.
I am interested in helping out with a transition to dracut. Besides testing, what might be the best way for me to contribute?
-- Jon
Le mercredi 03 avril 2013 à 08:19 -0500, Jon Nelson a écrit :
On Wed, Apr 3, 2013 at 4:34 AM, Raymond Wooninck tittiatcoke@gmail.com wrote:
On Wednesday 03 April 2013 12:13:50 Andrey Borzenkov wrote:
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer. I for one would like to see us switching to dracut yesterday.
I'm not sure I understand, what lacks maintainer - mkinitrd or dracut? In case of dracut I'd tentatively volunteer to (co-)maintain it.
Hi Andrey,
As Frederic already indicated mkinitrd seems to be the one missing the maintainership. However we would welcome any help we can get to really exploit dracut and to have it replace mkinitrd in openSUSE 13.1.
The main devel package is in the Base:System repository and currently Christian Rodriguez and I are maintaining it. A couple of months ago I took it upon me to get dracut into openSUSE, but unfortunately due to an work overload at my normal job, I am not able to spend that much time on it.
We are tracking the releases and the package is in openSUSE Factory. I guess the main thing to do is to validate if all angles are covered when using dracut to generate the inird instead of mkinitrd. This would be specifically with LUKS/crypt support.
I use LUKS for root and - while it took me a few tries - I do have a working system that boots just fine with either dracut or mkinitrd-built initrds. The key for me was that I had to refer to the (very good!) Fedora documentation to add: rd.auto to the kernel/initrd commandline.
Hmm, I haven't dig into dracut for sometime but you shouldn't have to do that (or something is wrong). Please open a bug report.
I still can't get dracut to decrypt my swap partition.
Same, open a bug report.
I am interested in helping out with a transition to dracut. Besides testing, what might be the best way for me to contribute?
I suggest to either use this mailing list or -factory mailing. If you find something broken, open a bug report, notify folks here and if you want to help fixing, indicate it in the bug report.
I would also suggest, if you can, to use irc channel on Freenode, #opensuse-factory and #dracut
(For folks interested, I'll probably work on dracut as my hackweek project next week, to help polish it so it could replace mkinitrd and also switch its internal to systemd).
В Wed, 3 Apr 2013 08:19:00 -0500 Jon Nelson jnelson-suse@jamponi.net пишет:
We are tracking the releases and the package is in openSUSE Factory. I guess the main thing to do is to validate if all angles are covered when using dracut to generate the inird instead of mkinitrd. This would be specifically with LUKS/crypt support.
I use LUKS for root and - while it took me a few tries - I do have a working system that boots just fine with either dracut or mkinitrd-built initrds.
May be I miss something obvious but I recently did several test installations on LVM on encrypted container and did not have a single issue except lack of out-of-the box support in grub2 (it is a single parameter in /etc/default/grub). But it was definitely *not* a problem in initrd or boot.crypto. And if you use separate /boot (which installer forces anyway) then it works out of the box using vanilla installer.
So may someone explain what are these problems with crypto mentioned here?
I could imagine problem with additional file systems but then it is out of scope for mkinitrd/dracut.
Stephan Kulow wrote:
On 03.04.2013 09:26, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer.
That's the information that was missing so far. At least it wasn't obvious to me. From a technical PoV I don't see the superiority of dracut. It looks like just another flavor of the same shell script mess. So by switching to dracut right now we would not switch to some next generation initrd that can to things in smarter ways.
I'm reluctant to waste time dealing with things like e.g. modules.d/90crypt/cryptroot-ask.sh. That feels like boot.crypto which was rightfully killed by systemd raising from the dead.
cu Ludwig
В Fri, 05 Apr 2013 13:20:54 +0200 Ludwig Nussel ludwig.nussel@suse.de пишет:
That's the information that was missing so far. At least it wasn't obvious to me. From a technical PoV I don't see the superiority of dracut. It looks like just another flavor of the same shell script mess. So by switching to dracut right now we would not switch to some next generation initrd that can to things in smarter ways.
dracut is being actively developed and is targeting toward full systemd integration. Having systemd in initrd sounds like being close to next generation to me.
I'm reluctant to waste time dealing with things like e.g. modules.d/90crypt/cryptroot-ask.sh. That feels like boot.crypto which was rightfully killed by systemd raising from the dead.
At some point you will have several systemd-cryptsetup services instead. Like this happened in booted OS now.
On 05.04.2013 13:20, Ludwig Nussel wrote:
Stephan Kulow wrote:
On 03.04.2013 09:26, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
A maintainer.
That's the information that was missing so far. At least it wasn't obvious to me. From a technical PoV I don't see the superiority of dracut. It looks like just another flavor of the same shell script mess. So by switching to dracut right now we would not switch to some next generation initrd that can to things in smarter ways.
I'm reluctant to waste time dealing with things like e.g. modules.d/90crypt/cryptroot-ask.sh. That feels like boot.crypto which was rightfully killed by systemd raising from the dead.
That's why dracut maintainers are working on integrating systemd into initrd - and mkinitrd maintainers are not.
Greetings, Stephan
On 04/03/2013 04:26 AM, Ludwig Nussel wrote:
Cristian Rodríguez wrote:
El 02/04/13 16:09, Christian Boltz escribió:
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
What exactly is dracut needed for there? Or to put it the other way around what's missing from mkinitrd?
Technically I would have to take a look more deeply to figure out exactly what. however.. what I know is that a bunch a people worked together making it work and took all upstream. thing that..well.we never did.
On 04/03/2013 04:42 AM, Cristian Rodríguez wrote:
what I know is that a bunch a people worked together making it work and took all upstream. thing that..well.we never did.
Of course this people did it for reason, they need it for for RHEL 7 ;)
Hello,
Am Dienstag, 2. April 2013 schrieb Cristian Rodríguez:
El 02/04/13 16:09, Christian Boltz escribió:
Nice[tm]. What's the reason for this? (I assume "let's break some initscripts from stone age" was not the reason - I seriously hope Lennart is not evil enough for that ;-)
Early boot scripts were a distribution specific extension of sysvinit, hence everybody does it differently.
To be more specific than Frederic, systemd no longer includes any distribution-specific code, all distributions targets (in our case TARGET_SUSE) are gone.
That still sums up to "let's break some initscripts from stone age". Seems like I have to add "on multiple distributions, so that everybody gets hurt".
Again: Is there a (technical) reason to remove the distro-specific code?
I start to think Lennart reads too many BOfH stories... :-(
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
... and dracut is not working on openSUSE yet if I understan the other mails correctly.
In other words: At the moment, RAID and LVM will _not_ work without the boot.* initscripts.
=== boot.loadmodules ===
Already sent a patch to replace it.
http://lists.opensuse.org/opensuse-kernel/2013-03/msg00016.html
Not merged yet :-( another reason to use dracut.
Reading the mails in opensuse-kernel, the migration will depend on the mkinitrd package. If we switch to dracut, you should also add it to another package that is actually installed ;-) (for example dracut or kernel-*)
=== boot.local === Package: file /etc/init.d/boot.local is not owned by any package # but should continue to work ;-)
Could replace that by a generator, or just call it "local.service".. ;)
As long as it works, I don't really care about the method ;-)
BTW: There might be more boot.* initscripts - my mail only listed those installed on my system. ARCHIVES.gz will probably give you a longer list.
[...]
Note that I didn't write anything about "remove the initscript" - for AppArmor, I'd like to keep it for backwards compability with older openSUSE releases. Other maintainers might or might not have similar wishes.
BTW: is ExecStatus supported in the meantime?
selinux and smack LSMs have native support merged in systemd (by the authors, Redhat and people from Intel respectively) kinda telling that apparmor doesn't...:-|
You most probably know that most of the AppArmor development is done by Ubuntu developers nowadays. [1]
Yes, that's the distribution with upstart. Not too surprising that they don't care about systemd, right?
That said: writing an apparmor.service file shouldn't be too hard, but at the moment I don't really have time to do it.
BTW: do the RPM macros for migration to *.service also work with boot.* initscripts? I had a look at /usr/sbin/systemd-sysv-convert, and I somehow doubt. It seems to check /etc/rc.d/rc*.d/ only, but not /etc/rc.d/boot.d/...
Talking about /usr/sbin/systemd-sysv-convert - even --help is buggy:
cat << EOF Save and Restore SusV Service Runlevel Information ^ ;-)
Regards,
Christian Boltz
[1] I'm also doing some work upstream, but that's mostly updating profiles and sometimes fixing some scripts. I also take part in discussions about future development, but you don't want me to write C code ;-) [2]
[2] if I ever write or edit C code, I strongly recommend to confine it with AppArmor *g*
El 03/04/13 15:29, Christian Boltz escribió:
Again: Is there a (technical) reason to remove the distro-specific code?
Yes, distribution specific code has to live in distributions trees.. not upstream.
Most, if not all, this "distribution specific" code have generic upstream replacements and we want to use them instead.
At the moment you'll break lots of packages and, more important, break lots of basic features like RAID and LVM.
RAID and LVM already have systemd support upstream, to make it work, last time I checked it required dracut.
... and dracut is not working on openSUSE yet if I understan the other mails correctly.
Yes, dracut works, what needs update is LVM and RAID ( update in the sense of "pull from upstream and test" )
In other words: At the moment, RAID and LVM will _not_ work without the boot.* initscripts.
Yes, in the current state of things that's correct.
Reading the mails in opensuse-kernel, the migration will depend on the mkinitrd package. If we switch to dracut, you should also add it to another package that is actually installed ;-) (for example dracut or kernel-*)
It can be accomodated elsewhere but ideally mkinitrd should close the door and turn the lights off on exit.
Note that I didn't write anything about "remove the initscript" - for AppArmor, I'd like to keep it for backwards compability with older openSUSE releases. Other maintainers might or might not have similar wishes.
Just add a conditional %{suse_version} < ... then
Le mardi 02 avril 2013 à 21:09 +0200, Christian Boltz a écrit :
BTW: is ExecStatus supported in the meantime?
No.
I remember some systemd folks had idea to implement it but it isn't very high on their TODO list.
(Needless to say that updating systemd is a no-go until all affected packages have a service file.)
You better hurry then, I'd like to update systemd next week in Factory ;)
Hello,
Am Mittwoch, 3. April 2013 schrieb Frederic Crozat:
Le mardi 02 avril 2013 à 21:09 +0200, Christian Boltz a écrit :
(Needless to say that updating systemd is a no-go until all affected packages have a service file.)
You better hurry then, I'd like to update systemd next week in Factory ;)
If I understand the other mails right, RAID and LVM would require dracut to work without their boot.* initscript, and dracut is not ready yet in openSUSE.
This sums up to the following options: a) break booting of all systems using RAID and/or LVM [1] by submitting the new systemd package b) first make sure RAID and LVM works without the boot.* initscript, and _after_ that is done, submit the new systemd package
I'd strongly recommend to avoid method a) ;-)
Regards,
Christian Boltz
[1] and maybe other critical parts I didn't notice yet
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Since openSUSE 12.3 has switched completely to systemd, no more new SysV-style init scripts should be written. Existing init scripts should be replaced with systemd service files and new packages should get only systemd service files.
Andreas
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Andreas maybe a simple example of how to convert a simple init script to a systemd service might be useful.
Alin
On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena alinm.elena@gmail.com wrote:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Andreas maybe a simple example of how to convert a simple init script to a systemd service might be useful.
http://0pointer.de/blog/projects/systemd-for-admins-3.html
Or is there anything more (open)SUSE specific?
nothing opensuse specific... just convenience... and you do not need the user to google all over to find something which is usually pretty trivial...
Alin Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ______________________________________________________________________
On 3 April 2013 13:07, Andrey Borzenkov arvidjaar@gmail.com wrote:
On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena alinm.elena@gmail.com wrote:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Andreas maybe a simple example of how to convert a simple init script to a systemd service might be useful.
http://0pointer.de/blog/projects/systemd-for-admins-3.html
Or is there anything more (open)SUSE specific?
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le mercredi 03 avril 2013 à 16:07 +0400, Andrey Borzenkov a écrit :
On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena alinm.elena@gmail.com wrote:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Andreas maybe a simple example of how to convert a simple init script to a systemd service might be useful.
http://0pointer.de/blog/projects/systemd-for-admins-3.html
Or is there anything more (open)SUSE specific?
No, fortunately, except maybe the RPM macros (which were written before systemd had its own set of macros and unfortunately, they diverge a bit ; I'll see if I can merge all of them in Factory).
Everything is explained at http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines
On 04/03/2013 09:07 AM, Andrey Borzenkov wrote:
Or is there anything more (open)SUSE specific?
No. there is (and really shouln't be) nothing opensuse-specific other than the rpm spec macros..
Le mercredi 03 avril 2013 à 14:48 -0300, Cristian Rodríguez a écrit :
On 04/03/2013 09:07 AM, Andrey Borzenkov wrote:
Or is there anything more (open)SUSE specific?
No. there is (and really shouln't be) nothing opensuse-specific other than the rpm spec macros..
And I plan to merge the "upstream" RPM macros in Factory to make sure both our openSUSE specific one and "upstream" one do the same thing.
El 03/04/13 09:01, Alin M Elena escribió:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Andreas maybe a simple example of how to convert a simple init script to a systemd service might be useful.
There is plenty of documentation how to do this, there is even a photo circulating on the internet with a printed manual filling TWO TOMES :-D
Hello,
On Apr 3 21:19 Cristian Rodríguez wrote:
El 03/04/13 09:01, Alin M Elena escribió:
On Wed 03 Apr 2013 13:55:33 Andreas Jaeger wrote:
I've added now at https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts the following:
Andreas maybe a simple example of how to convert a simple init script to a systemd service might be useful.
There is plenty of documentation how to do this, there is even a photo circulating on the internet with a printed manual filling TWO TOMES :-D
I do not understand such kind of answers. What was wrong with the question that Alin M Elena does not get a useful answer?
E.g. an appropriate URL where the requested information is.
Or perhaps someone who knows such an URL might even add it to https://en.opensuse.org/openSUSE:Packaging_guidelines#Init_scripts so that others who read that could also directly access the right information without using random stuff from the Internet.
Regards Johannes Meixner
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Andreas
I'm to lazy to read this exploding thread so please explain how I am supposed to package for openSUSE and SLE at the same time? I already got a declined sr because of that and I fail to see the review team discussion for that.
Also, I see people going crazy dropping init scripts for now reason. While it is true that openSUSE packagers should not care for SLE in general, they could care for the distros that are still in maintenance. Many (devel) projects provide packages for 12.1 even and there you have good reason to keep init scripts around.
How about a concrete example, I'm currently preparing chef-11 (the Erlang one) and want to submit it to Factory. My SUSE employee alter ego does that because we're going to make use of it in the SLE context. My openSUSE community member alter ego follows an upstream first policy, so I want it to be part of openSUSE (and thus Factory). However, even though I'm a big advocate of systemd, I couldn't care less for a service file ATM.
So it's either chef-11 for Factory w/o service file or I would have to move to IBS and then there's no chef-11.
On 04/05/2013 11:08 AM, Sascha Peilicke wrote:
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Andreas
I'm to lazy to read this exploding thread so please explain how I am supposed to package for openSUSE and SLE at the same time? I already got a declined sr because of that and I fail to see the review team discussion for that.
Also, I see people going crazy dropping init scripts for now reason. While it is true that openSUSE packagers should not care for SLE in general, they could care for the distros that are still in maintenance. Many (devel) projects provide packages for 12.1 even and there you have good reason to keep init scripts around.
How about a concrete example, I'm currently preparing chef-11 (the Erlang one) and want to submit it to Factory. My SUSE employee alter ego does that because we're going to make use of it in the SLE context. My openSUSE community member alter ego follows an upstream first policy, so I want it to be part of openSUSE (and thus Factory). However, even though I'm a big advocate of systemd, I couldn't care less for a service file ATM.
So it's either chef-11 for Factory w/o service file or I would have to move to IBS and then there's no chef-11.
In this case, you could add both init file and service file - or explain what you're doing with the submission, and I would be ok with it.
I don't see this guideline as a law but as guidance. So, let's talk about exceptions. And if you have a suggestion for a better wording then please propose one.
Andreas
On 04/05/2013 11:30 AM, Andreas Jaeger wrote:
On 04/05/2013 11:08 AM, Sascha Peilicke wrote:
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Andreas
I'm to lazy to read this exploding thread so please explain how I am supposed to package for openSUSE and SLE at the same time? I already got a declined sr because of that and I fail to see the review team discussion for that.
Also, I see people going crazy dropping init scripts for now reason. While it is true that openSUSE packagers should not care for SLE in general, they could care for the distros that are still in maintenance. Many (devel) projects provide packages for 12.1 even and there you have good reason to keep init scripts around.
How about a concrete example, I'm currently preparing chef-11 (the Erlang one) and want to submit it to Factory. My SUSE employee alter ego does that because we're going to make use of it in the SLE context. My openSUSE community member alter ego follows an upstream first policy, so I want it to be part of openSUSE (and thus Factory). However, even though I'm a big advocate of systemd, I couldn't care less for a service file ATM.
So it's either chef-11 for Factory w/o service file or I would have to move to IBS and then there's no chef-11.
In this case, you could add both init file and service file - or explain what you're doing with the submission, and I would be ok with it
Unfortunately I don't have the desire to spend time on that. I'm more than happy if someone wants to contribute service files (in general and my particular example).
I don't see this guideline as a law but as guidance. So, let's talk about exceptions. And if you have a suggestion for a better wording then please propose one.
Then reviews should not be declined based upon this guideline.
After some discussion with Sascha, we agreed that we have the following goals: * Moving to only systemd service files (while still supporting SysV init service files) * Supporting building with SLE 11 which comes with SysV init * The rcXXX script should continue to work with systemd
The first goal is not a hard goal.
So, we suggest to change the guideline to accomodate this better:
* If there is both an init file and a service file, install for openSUSE 12.3 and newer only the service file. * If the package is needed for SLE 11, you need at least a SysV init file * If you only support a service file, link rcXXX to /sbin/service so that rcXXX continues to work * If you submit a new package, consider your audience: Create a new service file for openSUSE 12.3 and newer - or a SysV init file for SLE 11.
You can (continue to) use the SysV init file for openSUSE, if you want - but consider adding a new service file, these are really easy to write.
Sascha & Andreas
On Mon, Apr 08, 2013 at 03:20:19PM +0200, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we have the following goals:
- Moving to only systemd service files (while still supporting SysV init
service files)
- Supporting building with SLE 11 which comes with SysV init
- The rcXXX script should continue to work with systemd
Hi,
can we have the rcXXX rpmlint error for that? I'm not sure how much systemd-only packages do we have atm and how many of them links /sbin/service in this case.
The first goal is not a hard goal.
So, we suggest to change the guideline to accomodate this better:
- If there is both an init file and a service file, install for openSUSE
12.3 and newer only the service file.
rpmlint error would be great as well
- If the package is needed for SLE 11, you need at least a SysV init file
- If you only support a service file, link rcXXX to /sbin/service so that
rcXXX continues to work
- If you submit a new package, consider your audience: Create a new
service file for openSUSE 12.3 and newer - or a SysV init file for SLE 11.
You can (continue to) use the SysV init file for openSUSE, if you want - but consider adding a new service file, these are really easy to write.
Last two sentences imho try to say the old "no new init scripts in Factory" rule using more void words. Or am I wrong?
Regards Michal Vyskocil
On 04/08/2013 01:08 PM, Michal Vyskocil wrote:
On Mon, Apr 08, 2013 at 03:20:19PM +0200, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we have the following goals:
- Moving to only systemd service files (while still supporting SysV init
service files)
- Supporting building with SLE 11 which comes with SysV init
- The rcXXX script should continue to work with systemd
Hi,
can we have the rcXXX rpmlint error for that? I'm not sure how much systemd-only packages do we have atm and how many of them links /sbin/service in this case.
rcXXX is a foreign concept not part of systemd , therefore there should be no expectative whatsoever about it working with systemd, even less an rpmlint error in place.
Le lundi 08 avril 2013 à 13:23 -0300, Cristian Rodríguez a écrit :
On 04/08/2013 01:08 PM, Michal Vyskocil wrote:
On Mon, Apr 08, 2013 at 03:20:19PM +0200, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we have the following goals:
- Moving to only systemd service files (while still supporting SysV init
service files)
- Supporting building with SLE 11 which comes with SysV init
- The rcXXX script should continue to work with systemd
Hi,
can we have the rcXXX rpmlint error for that? I'm not sure how much systemd-only packages do we have atm and how many of them links /sbin/service in this case.
rcXXX is a foreign concept not part of systemd , therefore there should be no expectative whatsoever about it working with systemd, even less an rpmlint error in place.
But it is an expectation from our users (openSUSE and SLE). We worked hard to make transition to systemd as smooth as possible and making sure rcXXX still works is part of that. We shouldn't drop it.
On 04/08/2013 01:40 PM, Frederic Crozat wrote:
But it is an expectation from our users (openSUSE and SLE). We worked hard to make transition to systemd as smooth as possible and making sure rcXXX still works is part of that. We shouldn't drop it.
Do you realize that rcxxx does not make any sense for a large number of services right ?
- Services that cannot be stopped - services cannot be started - Services that cannot be restarted - services on which it is meaningless and confusing, because they will be activated or stopped whenenever needed by udev, or by socket activation or dbus.
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE extension.
- systemctl has bash/zsh/etc completion for people that do not want to type larger commands.
Le lundi 08 avril 2013 à 14:00 -0300, Cristian Rodríguez a écrit :
On 04/08/2013 01:40 PM, Frederic Crozat wrote:
But it is an expectation from our users (openSUSE and SLE). We worked hard to make transition to systemd as smooth as possible and making sure rcXXX still works is part of that. We shouldn't drop it.
Do you realize that rcxxx does not make any sense for a large number of services right ?
- Services that cannot be stopped
- services cannot be started
- Services that cannot be restarted
- services on which it is meaningless and confusing, because they will
be activated or stopped whenenever needed by udev, or by socket activation or dbus.
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
- systemctl has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point here.
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
Dnia poniedziałek, 8 kwietnia 2013 14:07:40 Cristian Rodríguez pisze:
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
I do not think we should carry anachronic and confusing RC scripts. Those should be updated and cleaned up first.
IMHO, Chris
El mié 10 abr 2013 15:04:03 CLST, Křištof Želechovski escribió:
Dnia poniedziałek, 8 kwietnia 2013 14:07:40 Cristian Rodríguez pisze:
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
I do not think we should carry anachronic and confusing RC scripts. Those should be updated and cleaned up first.
Updating or cleaning them will not make them suddendly less confusing.
On Wed, Apr 10, 2013 at 03:14:20PM -0300, Cristian Rodríguez wrote:
El mié 10 abr 2013 15:04:03 CLST, Křištof Želechovski escribió:
Dnia poniedziałek, 8 kwietnia 2013 14:07:40 Cristian Rodríguez pisze:
On 04/08/2013 02:04 PM, Frederic Crozat wrote:
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
So we should carry them even when anachronic and confusing ?
I do not think we should carry anachronic and confusing RC scripts. Those should be updated and cleaned up first.
Updating or cleaning them will not make them suddendly less confusing.
Don't bee to much off-topic. Frederic and mine are tallking about rcXXX **symlinks**. Those hides the details about how service is spawned in sysvinit/systemd and don't need anything in /etc/init.d/ installed, having /usr/sbin/rcvsftpd -> /sbin/service will simply call systemctl.
I'm pretty sure this is tiny and nice advantage for SUSE users and shall not be removed.
Regards Michal Vyskocil
El 12/04/13 10:29, Michal Vyskocil escribió:
Don't bee to much off-topic. Frederic and mine are tallking about rcXXX **symlinks**. Those hides the details about how service is spawned in sysvinit/systemd and don't need anything in /etc/init.d/ installed, having /usr/sbin/rcvsftpd -> /sbin/service will simply call systemctl.
I am not off-topic, I think I am spot-on though :-)
rcfoo status --> meaningless or confusing when the service depends on a device that has not been plugged in yet, or when StopWhenUnneeded is set.
rcfoo start|stop
- meaningless or confusing the the unit file has RefuseManualStart or RefuseManualStop set, I assume you dont want to restrict usage of unit file options in order to preserve this illusion of compatibility do you ?
BUgzilla will probably speak louder & clearer and will certainly have more luck being listened to than me.
On Fri, Apr 12, 2013 at 4:40 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
rcfoo start|stop
- meaningless or confusing the the unit file has RefuseManualStart or
RefuseManualStop set, I assume you dont want to restrict usage of unit file options in order to preserve this illusion of compatibility do you ?
Why would it be meaningless?
It would tell you it refused to start|stop. That's all. As would invoking systemctl would. Is systemctl meaningless because it would refuse?
In any case, in those cases the package is configured as you say it's meaningless. We're all assuming discretionary judgement by the packager.
El vie 12 abr 2013 17:01:00 CLST, Claudio Freire escribió:
On Fri, Apr 12, 2013 at 4:40 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
rcfoo start|stop
- meaningless or confusing the the unit file has RefuseManualStart or
RefuseManualStop set, I assume you dont want to restrict usage of unit file options in order to preserve this illusion of compatibility do you ?
Why would it be meaningless?
It would tell you it refused to start|stop. That's all.
Yeah, but users expect sysvinit behaviour.. where there was no such thing as refusing to start or stop BECAUSE the init script said so, distinct from an error, misconfiguration..
This are the return values :
# Return values acc. to LSB for all commands but status: # 0 - success # 1 - generic or unspecified error # 2 - invalid or excess argument(s) # 3 - unimplemented feature (e.g. "reload") # 4 - user had insufficient privileges # 5 - program is not installed # 6 - program is not configured # 7 - program is not running # 8--199 - reserved (8--99 LSB, 100--149 distrib, 150--199 appl)
start , stop cannot fall under 3 "unimplemented" since those are mandatory under this old arse scenario :-P
In any case, in those cases the package is configured as you say it's meaningless. We're all assuming discretionary judgement by the packager.
Problem is rpmlint does not have discretionary judgement.
On Fri, Apr 12, 2013 at 5:38 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Why would it be meaningless?
It would tell you it refused to start|stop. That's all.
Yeah, but users expect sysvinit behaviour.. where there was no such thing as refusing to start or stop BECAUSE the init script said so, distinct from an error, misconfiguration..
Well, yes, expecting strict adherence to sysvinit behavior is ridiculous.
One thing is retaining functionality, and another is getting pedantic about how that functionality behaves, when the underlying system behaves different.
My point for rc scripts were, and I think others' too, about broad functionality, not the specific interface provided by sysvinit, but the general interface and ability to act on services beyond systemd's builtin actions, and within systemd's builtin actions, when those make sense.
If a user script fails because it cannot start a service that is now forbidden from starting manually, or to perform an action that indeed cannot be performed now, then that's an underlying failure of the scripts' assumptions that has to be adapted to the new system, and one wants that to fail. It's not a simple "this command has been renamed so I have to change 100 scripts".
In any case, in those cases the package is configured as you say it's meaningless. We're all assuming discretionary judgement by the packager.
Problem is rpmlint does not have discretionary judgement.
Ok, true, but packagers can add an rpmlintrc, so packagers do have discretionary judgement. The transition can be handled with warnings, increasing badness, whatever works.
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat fcrozat@suse.com wrote:
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
Not only that, rc scripts, when scripts and not just symlinks, provide a much-needed standardized way of getting to figure out the "extended status" of some services. Init scripts provided them when SysVinit was the only way, but I agree pegging extra functionality into SysVinit scripts was... dubious. However, having rc scripts provide said extra functionality makes a lot of sense.
And by extended status I mean something beyond systemd's "yeah, I started it - it ought to be running". Just try rcapparmor status on 12.2 to see how useless asking systemctl is.
- systemctl has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point here.
More than completion, I'd like to see systemctl accepting "abbreviated" service names, as in without the ".service" which is so very redundant, for starters.
- systemctl has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point here.
More than completion, I'd like to see systemctl accepting "abbreviated" service names, as in without the ".service" which is so very redundant, for starters.
You must love the speed we implement your wishes!
Frederic went ahead and commited your wish like... 6 months ago or so :)
Since we have systemd 193 (first shipped in 12.3 I think), you no longer have to specify the .service suffix.
.changes says:
- Changes from version 44 to 193: [..chatter..] + suffix ".service" may now be ommited on most systemctl command involving service unit names.
Cheers! Dominique
On Mon, Apr 8, 2013 at 2:39 PM, Dimstar / Dominique Leuenberger dimstar@opensuse.org wrote:
- systemctl has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point here.
More than completion, I'd like to see systemctl accepting "abbreviated" service names, as in without the ".service" which is so very redundant, for starters.
You must love the speed we implement your wishes!
Frederic went ahead and commited your wish like... 6 months ago or so :)
Since we have systemd 193 (first shipped in 12.3 I think), you no longer have to specify the .service suffix.
Lol, and I did test before writing it, but I'm now in 12.2. Kuddos :D
So yeah, I do love that wish-granting speed. I wish I was as fast at embracing those (ie, zypper dup).
Le lundi 08 avril 2013 à 19:39 +0200, Dimstar / Dominique Leuenberger a écrit :
- systemctl has bash/zsh/etc completion for people that do not want to
type larger commands.
Of course, I encourage people to use systemctl, but it is not the point here.
More than completion, I'd like to see systemctl accepting "abbreviated" service names, as in without the ".service" which is so very redundant, for starters.
You must love the speed we implement your wishes!
Frederic went ahead and commited your wish like... 6 months ago or so :)
Since we have systemd 193 (first shipped in 12.3 I think), you no longer have to specify the .service suffix.
For the record, upstream did this but I couldn't backport it for released distro (too invasive).
On 04/08/2013 02:33 PM, Claudio Freire wrote:
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat fcrozat@suse.com wrote:
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
Not only that, rc scripts, when scripts and not just symlinks,
As far as I am concerned is just a bunch of confusing unnecesary hacks that people apparently have an emotional attachment to.
Currently service much more than "running", "stopped".. the can be activated (and stopped) in a variety of ways.
provide
a much-needed standardized way of getting to figure out the "extended status" of some services. Init scripts provided them when SysVinit was the only way, but I agree pegging extra functionality into SysVinit scripts was... dubious. However, having rc scripts provide said extra functionality makes a lot of sense.
What do you mean ? systemctl does report the service status..
And by extended status I mean something beyond systemd's "yeah, I started it - it ought to be running". Just try rcapparmor status on 12.2 to see how useless asking systemctl is.
apparmor has to be hooked up to systemd the same way they other LSMs already are, nobody has done the required work though (unlike redhat or intel that paid people to do the work upstream)
On Mon, Apr 8, 2013 at 3:18 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
On 04/08/2013 02:33 PM, Claudio Freire wrote:
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat fcrozat@suse.com wrote:
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
Not only that, rc scripts, when scripts and not just symlinks,
As far as I am concerned is just a bunch of confusing unnecesary hacks that people apparently have an emotional attachment to.
Strip emotional, because that adjective is added by you without base of fact. You cannot know whether the attachment is emotional or of some other kind, since you do not share it.
But there is attachment, and attachment to some workflow must not be ignored, for it usually means it's a good workflow at some level. That the mistake, that is happening all over the place, with Gnome3 for instance, but not only, and is creating all sorts of uproar. Because people's workflow attachments are meaningful, no matter what an "enlightened developer" might think.
In this case, as rcscript functionality gets broken more and more by symlinking to systemctl, yeah, attachment will end up being emotional in the end, because none of the functionality that made it a rational kind of attachment remains.
But the point is, that when rc scripts add functionality, that is good, especially notably because people's attachment to them proves it's good.
And notice the conditiona. *When rc scripts add functionality*. By symlinking to systemctl, the only functionality left in them are as an alias. Might be a good functionality to keep if that prevents sysadmin scripts from breaking, but it's far less valuable than being able to quickly interact with services in a more complex manner than systemd understands.
Currently service much more than "running", "stopped".. the can be activated (and stopped) in a variety of ways.
Not sure what you mean here.
And by extended status I mean something beyond systemd's "yeah, I started it - it ought to be running". Just try rcapparmor status on 12.2 to see how useless asking systemctl is.
apparmor has to be hooked up to systemd the same way they other LSMs already are, nobody has done the required work though (unlike redhat or intel that paid people to do the work upstream)
Ok, maybe an LSM does indeed need to be supported by systemd specifically. But how does this rationale apply to other stuff? Just for an example I had to search for among all rc scripts... "rcntp ntptimeset".
On Mon 08 Apr 2013 04:11:07 PM CLST, Claudio Freire wrote: "rcntp ntptimeset".
ntptimeset --> timedatectl(1)
* Cristian Rodríguez crrodriguez@opensuse.org [04-08-13 15:24]:
On Mon 08 Apr 2013 04:11:07 PM CLST, Claudio Freire wrote: "rcntp ntptimeset".
ntptimeset --> timedatectl(1)
There appears to be some minor difficulty here also, left hand not knowing what right hand is doing????
15:37 Crash: ~ # timedatectl Local time: Mon, 2013-04-08 15:37:24 EDT Universal time: Mon, 2013-04-08 19:37:24 UTC RTC time: Mon, 2013-04-08 19:37:24 Timezone: America/Indiana/Indianapolis NTP enabled: no NTP synchronized: no RTC in local TZ: no
15:37 Crash: ~ # systemctl status ntp ntp.service - LSB: Network time protocol daemon (ntpd) Loaded: loaded (/etc/init.d/ntp) Active: active (running) since Sat, 2013-03-30 19:34:45 EDT; 1 weeks and 1 days ago CGroup: name=systemd:/system/ntp.service └ 4178 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf
Mar 30 19:34:45 Crash ntpd[4178]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Mar 30 19:34:45 Crash ntpd[4178]: Listen and drop on 1 v6wildcard :: UDP 123 Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 2 lo 127.0.0.1 UDP 123 Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 3 eth0 192.168.1.10 UDP 123 Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 4 lo ::1 UDP 123 Mar 30 19:34:45 Crash ntpd[4178]: Listen normally on 5 eth0 fe80::7271:bcff:fee9:3c0 UDP 123 Mar 30 19:34:45 Crash ntpd[4178]: peers refreshed Mar 30 19:34:45 Crash ntpd[4178]: Listening on routing socket on fd #22 for interface updates Mar 30 19:34:45 Crash ntp[4062]: Starting network time protocol daemon (NTPD)..done Mar 30 19:34:45 Crash systemd[1]: Started LSB: Network time protocol daemon (ntpd).
NTP not enabled/sync'ed or is it?
On 04/08/2013 04:41 PM, Patrick Shanahan wrote:
- Cristian Rodríguez crrodriguez@opensuse.org [04-08-13 15:24]:
On Mon 08 Apr 2013 04:11:07 PM CLST, Claudio Freire wrote: "rcntp ntptimeset".
ntptimeset --> timedatectl(1)
There appears to be some minor difficulty here also, left hand not knowing what right hand is doing????
NTP not enabled/sync'ed or is it?
yes, this is a side effect of the ntp daemon not been hooked up with the timedatectl functionality (lack of native units files and following the spec)
* Claudio Freire klaussfreire@gmail.com [04-08-13 15:13]: [...]
Ok, maybe an LSM does indeed need to be supported by systemd specifically. But how does this rationale apply to other stuff? Just for an example I had to search for among all rc scripts... "rcntp ntptimeset".
Using systemctl, I wonder how one would issue: rcapache2 graceful or:
reload|graceful - do a graceful restart by sending a SIGUSR1, or start if not running stop-graceful - stop httpd (sending SIGWINCH to parent)
configtest - do a configuration syntax test extreme-configtest - try to run httpd as nobody (detects more errors by actually loading the configuration, but cannot read SSL certificates) probe - probe for the necessity of a reload, give out the argument which is required for a reload. (by comparing conf files with pidfile timestamp)
full-server-status - dump a full status screen; requires lynx or w3m and mod_status enabled server-status - dump a short status screen; requires lynx or w3m and mod_status enabled
I do use systemd/systemctl but I also use rcapache2 for above function(s) and afaics, systemctl does not provide these. full-server-status
And have not seen it discussed in the opensuse lists. - dump a
On 04/08/2013 04:36 PM, Patrick Shanahan wrote:
- Claudio Freire klaussfreire@gmail.com [04-08-13 15:13]: [...]
Ok, maybe an LSM does indeed need to be supported by systemd specifically. But how does this rationale apply to other stuff? Just for an example I had to search for among all rc scripts... "rcntp ntptimeset".
Using systemctl, I wonder how one would issue: rcapache2 graceful
I do use systemd/systemctl but I also use rcapache2 for above function(s) and afaics, systemctl does not provide these. full-server-status
And have not seen it discussed in the opensuse lists. - dump a
It is implemented the following way..
systemctl restart apache2 --> is graceful restart
systemctl stop apache2 --> is graceful stop (when stopping systemd will issue TERM if the service refused to go down nicely after a timeout)
which is what you really want..
On 04/08/2013 04:11 PM, Claudio Freire wrote:
Currently service much more than "running", "stopped".. the can be activated (and stopped) in a variety of ways.
Not sure what you mean here.
I mean that the system no longer works the way rcxxx will produce meaninful output in many cases, many services will start on-demand, udev or desktop environments will ask for them when needed and will be garbage collected when unused.
There are oneshot services on which started/running/stopped does not make sense or static ones where any of those operations may not yield any meaning either.
Same thing with chkconfig for example, there are services that do not belong to any particular target/runlevel and hence reporting "on" or "off" is context,hardware or environment dependant (think containers, virtual machines, hotplugged devices) "being off" does not mean it will not start and being "on" is no indication of the reverse either.
On Mon, Apr 8, 2013 at 4:37 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
On 04/08/2013 04:11 PM, Claudio Freire wrote:
Currently service much more than "running", "stopped".. the can be activated (and stopped) in a variety of ways.
Not sure what you mean here.
I mean that the system no longer works the way rcxxx will produce meaninful output in many cases, many services will start on-demand, udev or desktop environments will ask for them when needed and will be garbage collected when unused.
There are oneshot services on which started/running/stopped does not make sense or static ones where any of those operations may not yield any meaning either.
I don't think that any of that matters for this conversation.
Rc scripts handle all those kinds of services, because rc scripts are tailored to the service, and options are added to them besides the standard start/stop. That's one point of rc scripts. They're the epitome of flexibility, even when that comes with a maintainership cost. But it's not the point I was trying to make.
Systemd has lots of holes understanding many of those kinds of services that don't just start/stop. Many of them that I've seen wrongfully treated as one-shot services, which is wrong, but nevertheless that doesn't mean systemd can't or shouldn't be taught about them.
No, my point wasn't about the service execution model, although I have mentioned the service execution model when ranting against systemd before.
My point this time was that there are lots of tasks related to services that don't pertain to starting or stopping them, and there's no hope of adding those to systemctl since they're so varied, nor would it be correct, and this is where rc scripts shine. They act as a central hub to general service administration, and it's good to have such a hub. It eases the sysadmin's task.
On 04/08/2013 05:33 PM, Claudio Freire wrote:
Rc scripts handle all those kinds of services, because rc scripts are tailored to the service, and options are added to them besides the standard start/stop.
That was a distribution extension of init scripts.
Systemd has lots of holes understanding many of those kinds of services that don't just start/stop.
No, however there is a massive hole of misunderstanding about how it works (or how it should work)
My point this time was that there are lots of tasks related to services that don't pertain to starting or stopping them, and there's no hope of adding those to systemctl since they're so varied, nor would it be correct, and this is where rc scripts shine. They act as a central hub to general service administration, and it's good to have such a hub. It eases the sysadmin's task.
The problem is, they were built for a model that does not exists anymore, it will just confuse sysadmins and will result in endless reports and rants about it.
As Im pretty sure I am right and this idea is wrong,I will just sit and watch the show, time will surely force the proponents to accept that you cannot keep an illusion alive for very long. unfortunately that also means it is gonna break badly sooner or later.
On Mon, Apr 8, 2013 at 6:36 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Systemd has lots of holes understanding many of those kinds of services that don't just start/stop.
No, however there is a massive hole of misunderstanding about how it works (or how it should work)
Perhaps. Time will tell.
My point this time was that there are lots of tasks related to services that don't pertain to starting or stopping them, and there's no hope of adding those to systemctl since they're so varied, nor would it be correct, and this is where rc scripts shine. They act as a central hub to general service administration, and it's good to have such a hub. It eases the sysadmin's task.
The problem is, they were built for a model that does not exists anymore, it will just confuse sysadmins and will result in endless reports and rants about it.
Motivation or origin doesn't matter. The merit of the tool itself does. And it's useful to be able to "rcservice what" or even just "rcservice" and be told about what you can do with it, beyond start/stop. Even "man service" would work. Thing is, "man service" rarely lists all the ways of starting and stopping the service which involve, sadly, mixing systemd, service-specific tools and/or sending signals to certain processes.
Furthermore, it's good to be able to "rcservice something" from scripts, and if the way of doing that somthing changes, the script won't break. That's called interface specification, something completely lacking of services in general, which rc scripts fill, and something every developer should know is needed.
As Im pretty sure I am right and this idea is wrong,I will just sit and watch the show, time will surely force the proponents to accept that you cannot keep an illusion alive for very long. unfortunately that also means it is gonna break badly sooner or later.
Great talking to you.
Hello,
Am Montag, 8. April 2013 schrieb Cristian Rodríguez:
On 04/08/2013 02:33 PM, Claudio Freire wrote:
And by extended status I mean something beyond systemd's "yeah, I started it - it ought to be running". Just try rcapparmor status on 12.2 to see how useless asking systemctl is.
Indeed. I'm still waiting (maybe praying helps?) for ExecStatus...
apparmor has to be hooked up to systemd the same way they other LSMs already are, nobody has done the required work though (unlike redhat or intel that paid people to do the work upstream)
Thinking about who could do or pay that - let me have a short look at the history of AppArmor...
Long time ago, Novell bought Immunix, renamed their "SubDomain" to "AppArmor" and had a new feature for SuSE Linux [1] and SLE. Some years later, interests changed (for whatever reason) and the AppArmor team was fired. Later some of them were hired by Canonical/Ubuntu, and that's where most of AppArmor development happens currently. Too bad that Ubuntu uses upstart...
If the systemd integration can be done in a scripting language (perl, bash etc.) and you want to pay me... ;-)
Otherwise someone @SUSE might be the perfect candidate to do it [2][3].
Regards,
Christian Boltz
[1] I didn't check, but I'm quite sure this happened in the "SuSE with lowercase u" timeframe
[2] Maybe someone is still looking for a hackweek project?
[3] <BoFH> I wonder how it will work in SLE12 ;-) </BoFH>
Le lundi 08 avril 2013 à 14:33 -0300, Claudio Freire a écrit :
On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat fcrozat@suse.com wrote:
- rcxxx symlinks were not part of sysvinit, it is yet another SUSE
extension.
Yes and we should carry it, because many of our users are still using it. Removing it just for the sake of removing it is absurd.
Not only that, rc scripts, when scripts and not just symlinks, provide a much-needed standardized way of getting to figure out the "extended status" of some services. Init scripts provided them when SysVinit was the only way, but I agree pegging extra functionality into SysVinit scripts was... dubious. However, having rc scripts provide said extra functionality makes a lot of sense.
And by extended status I mean something beyond systemd's "yeah, I started it - it ought to be running". Just try rcapparmor status on 12.2 to see how useless asking systemctl is.
Try it on 12.3 for initscripts which have a non-standard status output and you'll get both the "initscript" status + systemctl one.
But this stuff shouldn't be in initscript anyway.
On 04/08/2013 10:20 AM, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we have the following goals:
- Supporting building with SLE 11 which comes with SysV init
What about just asking people to create a different spec file instead of cluttering the actual ones with endless %if ? have you seen the mess this creates ? have you noticed that all this conditions are always added but never removed ?
Hello,
Am Montag, 8. April 2013 schrieb Cristian Rodríguez:
On 04/08/2013 10:20 AM, Andreas Jaeger wrote:
After some discussion with Sascha, we agreed that we have the following goals:
- Supporting building with SLE 11 which comes with SysV init
What about just asking people to create a different spec file instead of cluttering the actual ones with endless %if ? have you seen the mess this creates ? have you noticed that all this conditions are always added but never removed ?
A separate spec file? No thanks.
The %if might be annoying, but having multiple copies of the spec is like calling for problems. Those files _will_ get out of sync.
Been there, done that. Not with spec files, but with PHP code. The previous programmer used cp instead of if(). The result was that there were up to 4 copies of (nearly) the same code, but each copy came with a different set of bugs (typically bugs were fixed only in one place, the other copies still had the bug)...
Regards,
Christian Boltz
Hi Andi
Andreas Jaeger aj@suse.com schrieb:
I don't see this guideline as a law but as guidance. So, let's talk about exceptions. And if you have a suggestion for a better wording then please propose one.
As we have many guidelines for our packages, but less "laws", I always follow this direction when I review packages for factory:
* submission violates the law: reject (including hint or URL as reason)
* submission violates the guideline: accept (including hint or URL to the guideline asking to think about for next submission)
* submission does not violate anything above, but I have a bad feeling: ask other reviewers - or discuss directly with the packager. In worst case: reject
* submission does not violate anything above, but I have a hint for the packager: accept, including my hint
* …
My feeling is now that I am not a good reviewer as I accept too many packages. My hope is/was that packagers read my comments even if their package gets accepted for Factory. If this assumption is wrong, we should discuss what I can do instead.
Currently I do not like the idea to reject packages because of guideline violations, but if my notes are not read if I accept a package, than I should adapt to a better strategy. Suggestions welcome!
Lars
On Sun, Apr 7, 2013 at 7:03 AM, Lars Vogdt lrupp@suse.de wrote:
My feeling is now that I am not a good reviewer as I accept too many packages. My hope is/was that packagers read my comments even if their package gets accepted for Factory. If this assumption is wrong, we should discuss what I can do instead.
Currently I do not like the idea to reject packages because of guideline violations, but if my notes are not read if I accept a package, than I should adapt to a better strategy. Suggestions welcome!
It may not be at all bad to reject, if it's a guideline and it is clear that compliance is optional, the one that submitted can decide to reopen with a comment on why we would not comply. Either a compelling reason not to comply, or maybe something along the lines of "it would be too much work and it's better to push this fix sooner rather than later" would still be very informative.
It's a pity OBS doesn't let you add a comment without either accepting or rejecting.
On Sunday, April 07, 2013 12:03:10 Lars Vogdt wrote:
Hi Andi
Andreas Jaeger aj@suse.com schrieb:
I don't see this guideline as a law but as guidance. So, let's talk about exceptions. And if you have a suggestion for a better wording then please propose one.
As we have many guidelines for our packages, but less "laws", I always follow this direction when I review packages for factory:
- submission violates the law: reject (including hint or URL as
reason)
- submission violates the guideline: accept (including hint or URL to
the guideline asking to think about for next submission)
- submission does not violate anything above, but I have a bad
feeling: ask other reviewers - or discuss directly with the packager. In worst case: reject
- submission does not violate anything above, but I have a hint for
the packager: accept, including my hint
- …
My feeling is now that I am not a good reviewer as I accept too many packages. My hope is/was that packagers read my comments even if their package gets accepted for Factory. If this assumption is wrong, we should discuss what I can do instead.
There's always a line for interpretation - e.g. if the guidelines get updated, I would not enforce it necessarily for old submissions.
Currently I do not like the idea to reject packages because of guideline violations, but if my notes are not read if I accept a package, than I should adapt to a better strategy. Suggestions welcome!
I might be a bit more willing to reject submissions but IMO it's important to know that review is not final - if anybody disagrees with the review, reopening the request and adding a comment or mailing me directly is always fine.
I see a challenge with the notes if A submits to a devel projects, B accepts and forwards it - will A get your note - or only B? Packagers, are these review notes helpfull - or should we direct directly?
Andreas
Hello,
Am Montag, 8. April 2013 schrieb Andreas Jaeger:
On Sunday, April 07, 2013 12:03:10 Lars Vogdt wrote:
- submission violates the guideline: accept (including hint or URL
to the guideline asking to think about for next submission)
That sounds like a good way, especially if the SR touches an area that has nothing to do with the violated guideline.
I see a challenge with the notes if A submits to a devel projects, B accepts and forwards it - will A get your note - or only B?
AFAIK only B.
I'd prefer if A also gets a note - not only for a declined SR, but also when it's forwarded and when the forwarded request is accepted.
Sometimes I'd even want to CC on a "foreign" SR so that I'm updated about its status, but I didn't find a way how to do this.
Packagers, are these review notes helpfull - or should we direct directly?
IMHO the notes are helpful and a good idea - and less frustrating than declining the SR [1]. OTOH the notes might get lost, while a declined SR stays on the TODO list. It's probably a question of personal taste ;-)
Regards,
Christian Boltz
[1] you know what can happen - you declined one of my SRs some months ago, and the result were bugreports for two innocent developers ;-)
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Andreas
So we now have several people creating/copying service files for various packages with varying mileage. For instance, rabbitmq-server got one which forget some stuff present in the init script. While that is all fixable, I urge everyone to actually test those *.service files since they take precedence over init scripts.
Le mercredi 24 avril 2013 à 13:56 +0200, Sascha Peilicke a écrit :
On 03/29/2013 06:43 PM, Andreas Jaeger wrote:
Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore.
So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file,
Andreas
So we now have several people creating/copying service files for various packages with varying mileage. For instance, rabbitmq-server got one which forget some stuff present in the init script. While that is all fixable, I urge everyone to actually test those *.service files since they take precedence over init scripts.
We are also planning to initiate a cross-distribution .service pool, when services aren't upstreamed, to share files which are being written in various distributions.
It isn't announced yet (and help would be welcome to create a script to extract the various .service we have in the distribution) but it will be hosted on https://github.com/teg/systemd-units/
Le Wednesday 24 April 2013 à 13:56 +0200, Sascha Peilicke a écrit :
So we now have several people creating/copying service files for various packages with varying mileage. For instance, rabbitmq-server got one which forget some stuff present in the init script. While that is all fixable, I urge everyone to actually test those *.service files since they take precedence over init scripts.
Oh yeah. See for example: Bug 810344 - fancontol not starting https://bugzilla.novell.com/show_bug.cgi?id=810344
which was caused by an incomplete conversion of an init script to a service file.
Oh, I must push the fix as a maintenance update, BTW, thanks Sascha for the reminder.
-
Alin M Elena -
Alin Marin Elena
-
Andreas Jaeger -
Andrey Borzenkov -
Christian Boltz -
Claudio Freire -
Cristian Rodríguez -
Dimstar / Dominique Leuenberger -
Frederic Crozat -
Jean Delvare -
Johannes Meixner -
Jon Nelson -
Křištof Želechovski -
Lars Vogdt -
Ludwig Nussel -
Marcus Meissner -
Michael Matz -
Michal Kubecek -
Michal Kubeček
-
Michal Vyskocil -
Olav Vitters -
Patrick Shanahan -
Raymond Wooninck -
Sascha Peilicke -
Srinidhi B -
Stefan Seyfried -
Stephan Kulow -
Togan Muftuoglu -
Yamaban