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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 04/03/2013 04:42 PM, Yamaban wrote:

On Wed, 3 Apr 2013 09:20, 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 -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Thu, Apr 4, 2013 at 11:35 AM, Michal Kubeček 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sat, Apr 13, 2013 at 8:34 PM, Stefan Seyfried 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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? -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Sun, 14 Apr 2013 01:34:53 +0200 Stefan Seyfried пишет:

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). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

В Sat, 13 Apr 2013 19:34:44 -0300 Cristian Rodríguez пишет:

...

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sun, 14 Apr 2013 11:29, Stefan Seyfried wrote:

...

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

Am 14.04.2013 02:55, schrieb Cristian Rodríguez: 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.

В Sun, 14 Apr 2013 04:58:01 -0600 "Srinidhi B" пишет:

...

...

...

On 14/4/2013 at 03:52 PM, Yamaban wrote: On Sun, 14 Apr 2013 11:29, Stefan Seyfried wrote:

...

...

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

Am 14.04.2013 02:55, schrieb Cristian Rodríguez: 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sun, Apr 14, 2013 at 2:22 PM, Yamaban 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... -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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? -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On 04/17/2013 06:01 AM, Andrey Borzenkov wrote:

On Wed, Apr 17, 2013 at 12:28 PM, Stefan Seyfried 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? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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? -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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.

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.

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 ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Yamaban wrote:

On Wed, 3 Apr 2013 09:20, 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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- Doh, bad Steve, no donut! [...] That's what I got for copy&wasting from a diff. [Steve Beattie in apparmor] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Wed, Apr 3, 2013 at 11:35 AM, 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. 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- 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 à 08:19 -0500, Jon Nelson a écrit :

On Wed, Apr 3, 2013 at 4:34 AM, Raymond Wooninck 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). -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- Aussage eines Mathematikprofessors von mir: 'Die Informatiker, das sind die, die dann am Bahnsteig stehen, und ihre Koffer zählen - 0, 1, 2 - Mist, wo ist der dritte Koffer?' [Adalbert Michelic in suse-linux] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- 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 ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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

On Wed, Apr 3, 2013 at 4:01 PM, Alin M Elena 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

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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.. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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

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. -- Frederic Crozat SUSE -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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

On Fri, Apr 12, 2013 at 4:40 PM, Cristian Rodríguez 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Fri, Apr 12, 2013 at 5:38 PM, Cristian Rodríguez 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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

...

...

- 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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). -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Mon, Apr 8, 2013 at 3:18 PM, Cristian Rodríguez wrote:

On 04/08/2013 02:33 PM, Claudio Freire wrote:

...

On Mon, Apr 8, 2013 at 2:04 PM, Frederic Crozat 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". -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Cristian Rodríguez [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? -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

* Claudio Freire [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 -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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> -- Naja... wo ein Maildir ist, ist auch ein Dateisystem... also ein kleines Shellscript kochen (Gewürze: sed, awk, bash, evtl. auch einfach nur perl) [Sven Schumacher in postfixbuch-users] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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 ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

Hi Andi Andreas Jaeger 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 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

On Sunday, April 07, 2013 12:03:10 Lars Vogdt wrote:

Hi Andi

Andreas Jaeger 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 -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org

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. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org