On 17/12/11 10:06, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-12-17 13:59, Herbert Graeber wrote:

...

Read all of the the proposal. Fixing the bugs is part oft the process.

The proposal makes no sense till all the bugs are solved.

Bug numbers ? note that bugs in other components have nothing to do with systemd. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 17:41, Bernhard M. Wiedemann wrote:

https://bugzilla.novell.com/buglist.cgi?quicksearch=systemd

yes most of those are bugs elsewhere..

As I understood it, native unit files are not needed for the goal of fully switching to systemd and dropping sysvinit - so this step (and all other steps about /etc/init.d/ replacement) should be optional.

no, there should not be optional, as does solve the problem of supporting two different ways to do things.

Add documentation, HowTos etc. for developers and users of systemd and its service files so that they can tweak and extend their system as easily as with sysvinit. This might be inherently hard, because some things that used to be in easily changeable /etc/init.d/boot.* scripts were hardcoded into systemd's C code.

There is more documentation, than the old system ever had, including full grown how-tos to convert both units and daemons, example c code, libraries, tools, whatever..

This step will ideally still be some years ahead,

it cannot be some years ahead, we cannot support two systems for large periods of time, with the current amount of developer power is imho, completely out of the question.

so that as many use-cases as possible will be known to work with systemd.

your sugestion will actually delay those cases being known. People don't

like being forced into something that does not work properly.

It works, it has bugs like any software, and people complain for everything either if it works or not, without having any idea where the problem is. If they dont like it, they are free to find another distribution that does not "force" you to use it, that currently reduces to debian, gentoo, an a few other players. (ubuntu has upstart, mandriva,fedora, have systemd..etc) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 21:52, Rüdiger Meier wrote:

On Saturday 17 December 2011, Cristian Rodríguez wrote:

...

On 17/12/11 14:33, Vahis wrote:

...

Where is it?

In the official update repo..

...

Great fun! I just noticed that my boot.msg is quite old, December 4. Is that when it disappeared? Where can I now find what's running on the screen during boot?

all messages are logged to syslog , and can be found in /var/log/messages, later they will also be stored in journald binary log.

Is it also intenioned that there is no output on boot console at all? I'm using splash=native always but there is nothing...

On my serial console only systems this is all I get when booting: ------- root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-3.1.0-1.2-desktop root=/dev/vda2 noresume splash=native quiet console=ttyS0,115200 console=tty0 vga=0x314 [Linux-bzImage, setup=0x4200, size=0x4baef0] initrd /initrd-3.1.0-1.2-desktop [Linux-initrd @ 0x374a5000, 0xb4ad6f bytes] ----------

you have to remove "quiet" from the command line, if you want the splash to be chatty you have to use splash=verbose , it now does what is supposed to do ;) Not having a login prompt.. ? is the machine hanging ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 18/12/11 00:51, upscope wrote:

-------------- rpm -q --changelog systemd | less

* Fri Nov 04 2011 fcrozat@suse.com - Fix rpm macros to only call presets on initial install (bnc#728104).

that's not the package mentioned by Larry, though it will appear in an update soon.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 08:20, Peter Nikolic wrote:

On Saturday 17 December 2011 01:59:39 Carlos E. R. wrote:

...

...

This RFC proposes steps to permanently phase out sysvinit from future openSUSE releases. Not until systemd can be proved to work correctly in all cases. So far,

On Friday, 2011-12-16 at 18:37 -0300, Cristian Rodríguez wrote: the track record is awful. +1

it is still alpha qyality right now

Pete

+1 ditto Perhaps with greater understanding of how it works and better still with tools to manipulate it without the need for in-depth understanding, may be a "yast systemd". It's frustrating to find after switching to systemd, services that used to work without intervention now do not. We fully understood chkconfig which is simple and has been around for a long time. Your average users are not the guys who have picked their way through to understanding systemd and are very familiar with it. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot, Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-12-17 13:59, Herbert Graeber wrote:

Read all of the the proposal. Fixing the bugs is part oft the process.

The proposal makes no sense till all the bugs are solved. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk7sk8oACgkQtTMYHG2NR9UiAwCfUCR122XcxvTqTzUT03TW667v gCMAn3HlAEY06Fa1oQNIIKUxlNARsYDd =wfxV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 07:38, Sid Boyce wrote:

It's frustrating to find after switching to systemd,

Which services do not start? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

On 17/12/11 10:06, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-12-17 13:59, Herbert Graeber wrote:

...

Read all of the the proposal. Fixing the bugs is part oft the process.

The proposal makes no sense till all the bugs are solved.

Bug numbers ? note that bugs in other components have nothing to do with systemd.

But might still be related to your proposal. -- Per Jessen, Zürich (3.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

On 17/12/11 05:20, Peter Nikolic wrote:

...

it is still alpha qyality right now

Can you show your bug numbers ? or evidence to support your statement ?

Can you demonstrate the opposite? That ought to be part of your proposal. -- Per Jessen, Zürich (3.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 18/12/11 11:12, Sid Boyce wrote:

...

I enabled apache2.service in /lib/systemd/system.preset/default-openSUSE.preset but that didn't fix ce

That for sure is the wrong place.

Success! There is an apache2.service file in /lib/systemd/system

# ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/ Now apache2 starts automatically on boot. Regards Sid.

SO, it is not a bug after all, you simple missed what systemctl enable apache2.service is all about... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 13:45, Per Jessen wrote:

Not a service, but still an important bug that must be fixed before any talk of phasing out sysvinit:

Did you read the proposal? On completion there will be no init scripts but only native systemd units that log to syslog... and comment 5 provides a way to what you want. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 18/12/11 07:10, Wolfgang Rosenauer wrote:

Hi,

Am 17.12.2011 01:18, schrieb Cristian Rodríguez:

...

...

Add documentation, HowTos etc. for developers and users of systemd and its service files so that they can tweak and extend their system as easily as with sysvinit. This might be inherently hard, because some things that used to be in easily changeable /etc/init.d/boot.* scripts were hardcoded into systemd's C code.

There is more documentation, than the old system ever had, including full grown how-tos to convert both units and daemons, example c code, libraries, tools, whatever..

might be that systemd is documented. What still is not very comprehensive though is packager documentation for openSUSE's systemd migration. http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (this is simply not answering many questions)

http://en.opensuse.org/openSUSE:Systemd_status

I was able to find a solution/workaround for some of them. And I'm not sure if those break because I wasn't able to fully test them.

what is missing there so it can be improved ? do we want to duplicate the man pages or other documentation found in upstream ? http://www.freedesktop.org/wiki/Software/systemd I believe that's enough, at least is enough to get started for me :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Fri, Dec 16, 2011 at 4:37 PM, Cristian Rodríguez wrote:

Hi:

Supporting 2 different init systems comes with a large increase of possible usecases and scenarios that are very difficult to support correctly, specially in the long term.

This RFC proposes steps to permanently phase out sysvinit from future openSUSE releases.

Phase 0

- Fix all *currently* outstanding bugs of systemd if any, note that this step only deals with problems in systemd itself, not in service files installed by other packages, udev, kernel, networkmanager or whatever other thing.

- Determine which services currently lack of native systemd units.

- Add an rpmlint error with moderate badness for the start,complaining about the lack of unit files.

Phase 1:

- Delete sysvinit scripts that deal purely with hardware things,like only loading kernel modules, making udev to handle them or simple dropping a foobar.conf with the needed modules in /usr/lib/modules-load.d/ whichever is more adequate or doable.

- Add missing systemd units for the packages where rpmlint warns.

- Add rpmlint with badness complaining about logrotate, or other shell scripts calling files in /etc/init.d ...

Phase 3:

- Turn rpmlint warnings about the lack of systemd units on packages including traditional sysvinit scripts a fatal error.

- fix logrotate or shell scripts that are calling sysvint scripts and make the rpmlint warning a fatal error.

- tell RPM to %exclude files in /etc/init.d from packages, do not forc packagers to exclude these files themselves.

- make all macros relevant to traditional init scripts a no-op, do not force packagers to remove those lines or add extra hacks to the already horrendous hackery in spec files.

- test, test, test.

- remove sysvinit and all the relevant bootloader options and from the documentation.

-- ?????

-- Profit. :-)

This is just a quick brain dump, I am certainly missing something else.

Have fun.

Cristian.

Christian, A plan is great IF you have agreed on goals. Your implied goals are that all services should have FULLY native systemd support and that /etc/init.d should be GONE. Ignoring timeframe, I'm not aware that either of those are goals. I have seen it posted repeatedly that systemd supports scripts in /etc/init.d, so it is not obvious to me that your assumed goals are in fact opensuse community goals. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 14:12, Per Jessen wrote: but I think we should also consider

what to do about third party products or packages that are unlikely to upgrade to systemd or where an upgrade is not expected before our first release without sysvinit support. I know this is difficult, but people who are using third party products could list them. Examples I have myself - the HP Proliant Support Pack and 3ware init-scripts.

Third party packages cannot be fixed by opensuse neither we should stop doing things just because some other provider does not fix their stuff.(will fail on fedora, mandriva and other distros that are in this same boat too) If we consider this argument then nothing will go forward, the number of usecase scenarios become unmanageable and will be forever stuck if we care about crap packages provided by someone else. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 18/12/11 06:13, Bernhard M. Wiedemann wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 17.12.2011 01:18, schrieb Cristian Rodríguez:

...

On 17/12/11 17:41, Bernhard M. Wiedemann wrote:

...

https://bugzilla.novell.com/buglist.cgi?quicksearch=systemd

yes most of those are bugs elsewhere..

bugs that only occur because of systemd can not be ignored when you want to drop the working alternative.

If I dont' narrow down the proposal, the number of different scenarios go to the roof.

let's have an example - I used to adapt the timeout for mounting my crypted home partition. By looking at /etc/init.d/boot.crypto I found that /lib/cryptsetup/boot.crypto.functions contains a TIMEOUT value of 120 seconds, which I then change with a text editor and will thus be used on next boot. Systemd does not use /etc/init.d/boot.* files

with "find" I found /lib/systemd/systemd-cryptsetup (binary - so unreadable)

Yes, that's because systemd interfaces with libcryptsetup .. and

/lib/systemd/system/cryptsetup.target

which mentions man 7 systemd.special but this manual page does not even mention "crypt" once. And nothing about "timeout" either.

Did you filled a bug report ?

Where does the support effort come from (aside from fixing bugs that need fixing anyway)?

bit rotting.

I can see some effort in maintaining /etc/init.d/boot.* files together with their systemd equivalent.

Some of them will probably go away as systemd handles them natively.

are we in a hurry?

The sooner the better, people will eb able to direct efforts into one thing, that has ONE particular set of rules. Im all for choice, but in this scenario it is not healthy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

On 17/12/11 14:23, Vahis wrote:

...

Larry Finger wrote:

...

...

zypper in -f http://download.opensuse.org/repositories/home:/fcrozat:/systemd/openSUSE_12...

that pdated is already scheduled to be published to users for 12.1

...

I installed that version but I still need to start postfix in YaST.

You are installing then, the wrong update..you have to update postfix.

Where is it?

...

/var/log/boot.msg does not show those.

boot.msg has gone away, and is afaik, not coming back.

Great fun! I just noticed that my boot.msg is quite old, December 4. Is that when it disappeared? Where can I now find what's running on the screen during boot? Vahis -- http://waxborg.servepics.com openSUSE 11.4 (x86_64) 2.6.37.6-0.9-default main host openSUSE 12.1 (x86_64) 3.1.1-48-desktop Tumbleweed in VirtualBox openSUSE 12.1 (i586) 3.1.0-1.2-desktop in EeePC 900 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Dec 17, 2011 at 12:33 PM, Cristian Rodríguez wrote:

...

Your implied goals are that all services should have FULLY native systemd support and that /etc/init.d should be GONE.

Yes, from packages installed by the distribution, I have said nothing about user provided scripts neither about removing sysinit support from systemd, I am talking about the default installation.

 > Ignoring timeframe, I'm not aware that either of those are goals.  I

...

have seen it posted repeatedly that systemd supports scripts in /etc/init.d, so it is not obvious to me that your assumed goals are in fact opensuse community goals.

If this is not a goal, then goals are wrong and plain madness.

I have no idea, I'm just saying I haven't seen it stated and the implications have been the opposite if anything. ie. I have repeatedly seen it posted that systemd support can be achieved by leveraging the existing scripts in /etc/init.d. So before arguing for or against your plan, a new thread discussing the goals seems to make sense. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 17 December 2011 16:54:33 Cristian Rodríguez wrote:

On 17/12/11 13:46, Per Jessen wrote:

...

Can you demonstrate the opposite?

That's absurd, you cannot prove a negative, those who claiming it is "alpha", "broken" has to demonstrate their claims.

I can prove it is broken very easily i am unable to boot a nerw install of 12.1 using systemd but if i force sysvinit it boots perfectly therefore it is BROKEN Borked look ay it how ever you want it don't work so it is busted I rest my case. Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.10-0.4-desktop KDE Development Platform: 4.6.5 (4.6.5) "release 7" 17:46 up 3:18, 4 users, load average: 0.21, 0.45, 0.38 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Dec 17, 2011 at 12:45 PM, Cristian Rodríguez wrote:

On 17/12/11 14:38, Greg Freemyer wrote:

...

So before arguing for or against your plan, a new thread discussing the goals seems to make sense.

It has to :) simple because going into the two init systems path is not a supportable option, it essentially increases complexity and the number of usecases exponentially.

Maybe I'm missing something, but: A goal of eliminating the package sysvinit and the associated run levels is one thing. A goal of re-coding all of the init scripts in /etc/init.d to be native systemd units is something else. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

On 17/12/11 14:12, Per Jessen wrote:

...

but I think we should also consider what to do about third party products or packages that are unlikely to upgrade to systemd or where an upgrade is not expected before our first release without sysvinit support. I know this is difficult, but people who are using third party products could list them. Examples I have myself - the HP Proliant Support Pack and 3ware init-scripts.

Third party packages cannot be fixed by opensuse neither we should stop doing things just because some other provider does not fix their stuff.(will fail on fedora, mandriva and other distros that are in this same boat too)

Yep.

If we consider this argument then nothing will go forward, the number of usecase scenarios become unmanageable and will be forever stuck if we care about crap packages provided by someone else.

It wasn't meant as an argument either way, only as a factor to consider. People who depend on such packages would be left in the lurch. One option is to say "well, sorry, but you're stuffed". I just think we should state this up front. -- Per Jessen, Zürich (2.9°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 14:51, Greg Freemyer wrote:

A goal of eliminating the package sysvinit and the associated run levels is one thing.

Yes, but *after* providing all missing systemd native units. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Carlos E. R. [12-17-11 08:07]:

On 2011-12-17 13:59, Herbert Graeber wrote:

...

Read all of the the proposal. Fixing the bugs is part oft the process.

The proposal makes no sense till all the bugs are solved.

If you consider that many bugs will not even be seen until a *forced* migration, ie: no sysvinit available, is achieved. So reaching systemd default will not be achieved either. -- (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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 18/12/11 15:39, Vahis wrote:

Cristian Rodríguez wrote:

...

On 18/12/11 14:27, Vahis wrote:

...

...

I did same thing (just copied it from the post) with postfix in my 64 bit 12.1:

ln -s /lib/systemd/system/postfix.service /etc/systemd/system/multi-user.target.wants

and now it starts.

You have to use systemctl enable postfix.service, the symlink is created as a result of that command.

So is it meant to be that system mail doesn't run by default?

services started by default have to be mentioned in systemd-presets-branding-openSUSE package though postfix is, there was a bug in the package,

Is this a bug or an intended behavior?

In this particular case, there WAS a bug... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/17/2011 06:33 AM, Thomas Leineweber wrote:

Am 17.12.2011 14:06, schrieb Carlos E. R.:

...

On 2011-12-17 13:59, Herbert Graeber wrote:

...

Read all of the the proposal. Fixing the bugs is part oft the process. The proposal makes no sense till all the bugs are solved.

if you want to stall every proposal until all bugs are provably solved, you would go nowhere. Once again from me: Read the whole proposal. Phase 0 includes fixing the known bugs in systemd. If you think there are bugs, tell about them in bugzilla. Otherwise, your bugs can not be fixed. Yes, there will be additional new bugs, but this is to be expected.

I am in favor of the proposal. It is a nightmare to support two different init systems. Systemd has the backward compatibility to use the old sysv init-scripts, and there is no plan to disallow them tomorrow.

Thomas

I agree, it's a nightmare.... systemd is. ignore it until it's ready for primetime. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday, December 17, 2011 12:54:28 PM Cristian Rodríguez wrote:

On 17/12/11 07:38, Sid Boyce wrote:

...

It's frustrating to find after switching to systemd,

Which services do not start?

Network does not start everytime. It is needed by apache2. I have to manually start it. I have: code ---------- rpm -qa |grep systemd systemd-37-3.4.1.x86_64 systemd-presets-branding-openSUSE-0.1.0-6.2.1.noarch systemd-32bit-37-3.4.1.x86_64 systemd-sysvinit-37-3.4.1.x86_64 is the version mentioned in Larry Fingers thread later than the one I have? ------- Russ openSUSE 12.1(Linux 3.1.0-1.2-desktop x86_64)|KDE Platform Version 4.7.4 (4.7.4) Release "11"|Intel core2duo 2.5 MHZ, |8GB DDR3| GeForce 8400GS (NVIDIA-Linux-x86_64-285.05.09) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Samstag, 17. Dezember 2011, 17:48:22 schrieb Peter Nikolic:

On Saturday 17 December 2011 16:54:33 Cristian Rodríguez wrote:

...

On 17/12/11 13:46, Per Jessen wrote:

...

Can you demonstrate the opposite?

That's absurd, you cannot prove a negative, those who claiming it is "alpha", "broken" has to demonstrate their claims.

I can prove it is broken very easily i am unable to boot a nerw install of 12.1 using systemd but if i force sysvinit it boots perfectly therefore it is BROKEN Borked look ay it how ever you want it don't work so it is busted

Your claim: It's broken, because it's broken for me. The only thing you have proven is that it does not work *for you*. In fact you did not even go into details, i.e. you don't know if it's really only systemd causing the issue or if it is only playing its part and something else at fault, e.g. a broken script. So while your claim that it is broken would be valid if you added the "for me", its validity to prove it's alpha is close to zero. And it is not even helpful towards improving the situation for you. So in total it's useless. People who have it working will not care to report others' issues. In fact, they can't. And according to your logic somebody who has it working can claim: It's working, because it's working for me. I guess you would not accept that, yet demand it the other way around… So please do not post generalisations but specific issues. It's more useful, it makes you look less trollish and it could actually state a valid case to not phase out systemvinit yet. Sven -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2011-12-17 18:24, Cristian Rodríguez wrote:

Third party packages cannot be fixed by opensuse neither we should stop doing things just because some other provider does not fix their stuff.(will fail on fedora, mandriva and other distros that are in this same boat too)

But they hurt users.

If we consider this argument then nothing will go forward, the number of usecase scenarios become unmanageable and will be forever stuck if we care about crap packages provided by someone else.

It pains me that you do not have pity on us users. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk7s+58ACgkQtTMYHG2NR9Wc/ACePmguVA9f0eIH7DUQRo1Junjj yxAAniSp2JeQoa+6dkeNY8kUFahT2oDp =Ne77 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 16.12.2011 22:37, schrieb Cristian Rodríguez:

Hi:

Supporting 2 different init systems comes with a large increase of possible usecases and scenarios that are very difficult to support correctly, specially in the long term.

This RFC proposes steps to permanently phase out sysvinit from future openSUSE releases.

Phase 0

- Fix all *currently* outstanding bugs of systemd https://bugzilla.novell.com/show_bug.cgi?id=696902 tracks several systemd-related bugs in the "Depends On" section and there are currently 32 open bugs at: https://bugzilla.novell.com/buglist.cgi?quicksearch=systemd

note that this step only deals with problems in systemd itself, not in service files installed by other packages, udev, kernel, networkmanager or whatever other thing.

We need to address bugs in other components (that did not occur with sysvinit) to avoid regressions.

- Determine which services currently lack of native systemd units.

As I understood it, native unit files are not needed for the goal of fully switching to systemd and dropping sysvinit - so this step (and all other steps about /etc/init.d/ replacement) should be optional. [...cut...] Add documentation, HowTos etc. for developers and users of systemd and its service files so that they can tweak and extend their system as easily as with sysvinit. This might be inherently hard, because some things that used to be in easily changeable /etc/init.d/boot.* scripts were hardcoded into systemd's C code.

- test, test, test.

- remove sysvinit and all the relevant bootloader options and from the documentation.

This step will ideally still be some years ahead, so that as many use-cases as possible will be known to work with systemd. People don't like being forced into something that does not work properly.

-- ?????

-- Profit. :-)

Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7s/oMACgkQSTYLOx37oWT+GACfSG/sZlsimxylGyzfYkUYY7rH IEgAn06TypmVkFSRJDn/vMjsD32lzsCE =E+2E -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/17/2011 01:26 PM, upscope wrote:

is the version mentioned in Larry Fingers thread later than the one I have?

I think it is. For that version, the YaST Change Log says it was built on December 7. I still have to original version on another machine - it was built on November 4. The new version should be appearing as an update, but I do not know when. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

On 2011-12-17 13:59, Herbert Graeber wrote:

...

...

Read all of the the proposal. Fixing the bugs is part oft the process. The proposal makes no sense till all the bugs are solved.

What we need is a list of all unknown bugs. ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 17 December 2011, Cristian Rodríguez wrote:

On 17/12/11 14:33, Vahis wrote:

...

Where is it?

In the official update repo..

...

Great fun! I just noticed that my boot.msg is quite old, December 4. Is that when it disappeared? Where can I now find what's running on the screen during boot?

all messages are logged to syslog , and can be found in /var/log/messages, later they will also be stored in journald binary log.

Is it also intenioned that there is no output on boot console at all? I'm using splash=native always but there is nothing... On my serial console only systems this is all I get when booting: ------- root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-3.1.0-1.2-desktop root=/dev/vda2 noresume splash=native quiet console=ttyS0,115200 console=tty0 vga=0x314 [Linux-bzImage, setup=0x4200, size=0x4baef0] initrd /initrd-3.1.0-1.2-desktop [Linux-initrd @ 0x374a5000, 0xb4ad6f bytes] ---------- No boot messages. No login prompt. Can't even login to see what's going on. Booting with sysvinit works as expected. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday 17 December 2011, Cristian Rodríguez wrote:

On 17/12/11 21:52, Rüdiger Meier wrote:

...

On Saturday 17 December 2011, Cristian Rodríguez wrote:

...

On 17/12/11 14:33, Vahis wrote:

...

Where is it?

In the official update repo..

...

Great fun! I just noticed that my boot.msg is quite old, December 4. Is that when it disappeared? Where can I now find what's running on the screen during boot?

all messages are logged to syslog , and can be found in /var/log/messages, later they will also be stored in journald binary log.

Is it also intenioned that there is no output on boot console at all? I'm using splash=native always but there is nothing...

On my serial console only systems this is all I get when booting: ------- root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-3.1.0-1.2-desktop root=/dev/vda2 noresume splash=native quiet console=ttyS0,115200 console=tty0 vga=0x314 [Linux-bzImage, setup=0x4200, size=0x4baef0] initrd /initrd-3.1.0-1.2-desktop [Linux-initrd @ 0x374a5000, 0xb4ad6f bytes] ----------

you have to remove "quiet" from the command line, if you want the splash to be chatty you have to use splash=verbose , it now does what is supposed to do ;)

Hm, in past "quiet" skipped kernel messages only like these ones: .... [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009bc00 (usable) [ 0.000000] BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000003fffd000 (usable) [ 0.000000] BIOS-e820: 000000003fffd000 - 0000000040000000 (reserved) [ 0.000000] BIOS-e820: 00000000feffc000 - 00000000ff000000 (reserved) [ 0.000000] BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved) ..... I see them on sysvinit without "quiet" too but I don't need them. All I need is the userspace output of init scripts but anyway.

Not having a login prompt.. ? is the machine hanging ?

It's "working" but I can't login from serial console. Now without quiet it ends this way: ------------- [ 13.711255] device-mapper: uevent: version 1.0.3 [ 13.720722] device-mapper: ioctl: 4.21.0-ioctl (2011-07-06) initialised: dm-devel@redhat.com [ 14.508873] alsactl[576]: /usr/sbin/alsactl: load_state:1586: Cannot open /var/lib/alsa/asound.state for reading: No such file or directory ------------ (BTW I don't even have a sound card) I would expect something like this: ------------ [...] Starting mail service (Postfix) done Starting CRON daemon done Starting smartd unused Master Resource Control: Running /etc/init.d/after.local done Master Resource Control: runlevel 3 has been reached Skipped services in runlevel 3: cpufreq microcode.ctl smartd Welcome to openSUSE 12.1 "Asparagus" - Kernel 3.1.0-1.2-desktop (ttyS0). factory login: ------------------- cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Friday, December 16, 2011 09:53:28 PM Cristian Rodríguez wrote:

On 17/12/11 21:39, Sid Boyce wrote:

...

On 17/12/11 15:54, Cristian Rodríguez wrote:

...

On 17/12/11 07:38, Sid Boyce wrote:

...

It's frustrating to find after switching to systemd,

Which services do not start?

I rebooted a laptop with Factory and a vanilla kernel 3.2-rc5+ and apache2 didn't start up. It looks better than last time I tried it but I have not had a good hunt around. Last time /etc/init.d/vboxdrv didn't work and apache2 also did not start. I had to go into /etc/init.d and use "./vboxdrv setup" and "./apache2 start".

and what makes you think this is a problem with systemd ? virtualbox not loading modules is a bug in virtualbox, that should not load modules with init scripts, see my proposal on the topic.

post your apache problem in a bug report, CC to me..

btw.. that's odd because I do maintain a webserver that has systemd running and I have not seen this problem. My apache problem usually occurs when phpMyAdmin has an error and fails. Then I look at services and network is stopped. i restart it and then I am able to start phpMyAdmin. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Dec 17, 2011 at 9:29 PM, Greg Freemyer wrote:

On Fri, Dec 16, 2011 at 4:37 PM, Cristian Rodríguez wrote:

...

Hi:

Supporting 2 different init systems comes with a large increase of possible usecases and scenarios that are very difficult to support correctly, specially in the long term.

This RFC proposes steps to permanently phase out sysvinit from future openSUSE releases.

Phase 0

- Fix all *currently* outstanding bugs of systemd if any, note that this step only deals with problems in systemd itself, not in service files installed by other packages, udev, kernel, networkmanager or whatever other thing.

- Determine which services currently lack of native systemd units.

- Add an rpmlint error with moderate badness for the start,complaining about the lack of unit files.

This much seems useful regardless of anything else,

"Assuming" it can be done.  How would rpmlint know that a package needs a unit file?  After all, most don't.

Also, is there a way the "badness" could be made more obvious.

I don't think any of my packages have a init script, but if they did having a ever increasing badness would be totally hidden from me unless I happen to be looking at the build log.  For stable packages, I don't suspect many of us do that.

The badness could be set to 100000 or something like that that automatically terminates the build. Once this happens, I see three solutions to allowing building: 1. Have users add an rplintrc file. We can simply keep an eye on rplintrc files. 2. The same as 1, but also require users submit a bug report or put the file in a wiki to have the issue fixed. 3. Discourage users from using an rplintrc file. Instead have them submit a bug report only, and have the file added to an rpmlintrc whitelist, similar to dbus security checks currently. 1 would be easiest initially but make follow-up tracking harder. 3 I think would make things harder for everyone. I think 2 is better, probably with a bug report since this works for people who don't have wiki access. There could be a proper tag or something for bugs in this category so they can be easily tracked. Using bug reports would also allow more substantial discussion of how to best fix the issue on a case-by-case basis, allow for proposed scripts to be attached and discussed, and overall allows for a more robust and transparent decision-making process. Although technically 2 and 3 are not mutually exclusive, you could always let users use an rpmlintrc as a temporary workaround until the file is added to the whitelist, I just don't see any advantage to this method, and packagers will probably ignore the message and use an rpmlintrc file anyway. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Am 17.12.2011 01:18, schrieb Cristian Rodríguez:

...

Add documentation, HowTos etc. for developers and users of systemd and its service files so that they can tweak and extend their system as easily as with sysvinit. This might be inherently hard, because some things that used to be in easily changeable /etc/init.d/boot.* scripts were hardcoded into systemd's C code.

There is more documentation, than the old system ever had, including full grown how-tos to convert both units and daemons, example c code, libraries, tools, whatever..

might be that systemd is documented. What still is not very comprehensive though is packager documentation for openSUSE's systemd migration. http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (this is simply not answering many questions) http://en.opensuse.org/openSUSE:Systemd_status I was able to find a solution/workaround for some of them. And I'm not sure if those break because I wasn't able to fully test them. I understand that some issues are basically obsolete if sysvinit support is gone anyway (probably that's one of the reasons for the proposal?). Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 18/12/11 01:35, Sid Boyce wrote:

On 17/12/11 00:53, Cristian Rodríguez wrote:

...

On 17/12/11 21:39, Sid Boyce wrote:

...

On 17/12/11 15:54, Cristian Rodríguez wrote:

...

On 17/12/11 07:38, Sid Boyce wrote:

...

It's frustrating to find after switching to systemd,

Which services do not start?

I rebooted a laptop with Factory and a vanilla kernel 3.2-rc5+ and apache2 didn't start up. It looks better than last time I tried it but I have not had a good hunt around. Last time /etc/init.d/vboxdrv didn't work and apache2 also did not start. I had to go into /etc/init.d and use "./vboxdrv setup" and "./apache2 start".

and what makes you think this is a problem with systemd ? virtualbox not loading modules is a bug in virtualbox, that should not load modules with init scripts, see my proposal on the topic.

Just reporting what I saw without apportioning blame to anyone. I shall have to check but I think I posted a bug to the VirtualBox forum some time ago when I also reported a module build problem with latest vanilla kernels. I got a fix and they promised it will be rolled into the next release. No word back on the vboxdrv issue.

...

post your apache problem in a bug report, CC to me..

btw.. that's odd because I do maintain a webserver that has systemd running and I have not seen this problem.

Bug #737524 submitted.

Regards Sid.

I enabled apache2.service in /lib/systemd/system.preset/default-openSUSE.preset but that didn't fix it on a reboot. I had to issue "service apache2 start". However, this time VirtualBox modules were automatically loaded. Bug #737524 updated. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot, Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, Am Freitag, 16. Dezember 2011 schrieb Cristian Rodríguez:

On 17/12/11 17:41, Bernhard M. Wiedemann wrote:

...

As I understood it, native unit files are not needed for the goal of fully switching to systemd and dropping sysvinit - so this step (and all other steps about /etc/init.d/ replacement) should be optional. no, there should not be optional, as does solve the problem of supporting two different ways to do things.

So I have to add this line to %build: mv $BUILDROOT/etc/init.d/boot.apparmor $BUILDROOT/lib/apparmor/ and to add an apparmor.service file that calls /lib/apparmor/boot.apparmor start Mission accomplished, according to your proposal, and rpmlint will also be happy *eg* Don't get me wrong: I fully understand that maintaining systemd _and_ sysvinit will become a pain, but I don't see a point in forcing everybody to migrate to *.service files instantly. (And I'm saying this as someone who really prefers the short *.service files over the quite long and verbose initscripts because the initscripts contain lots of duplicated code.) The migration might make sense (and is easy) for starting programs where you can "write" an initscript with sed 's/FOO/mydaemon' < /etc/init.d/skeleton > /etc/init.d/mydaemon OTOH, there are init scripts like boot.apparmor which don't start a daemon, but instead do lots of other things (like loading all AppArmor profiles in /etc/apparmor.d/). AFAIK I _have to_ use a script for doing that, and it would probably double the maintenance effort if you force me not to use the existing init script. Now tell me how to do this in a *.service file without using a script (extremely simplified version of loading the AppArmor profiles): ls -1 /etc/apparmor.d/ | grep -v 'rpmnew$\|rpmold$' | \ while read profile ; do apparmor_parser "/etc/apparmor.d/$profile" done To avoid over-simplifying it, let me just mention that you have to use apparmor_parser -r "$profile" on reload, except if a profile was not loaded previously (which you can find out by reading somewhere in /proc). And you have to unload all profiles listed somewhere in /proc on "stop". Is there a better solution than calling the good old initscript? ;-) I already mentioned the easiest "fix" I could use at the beginning of the mail, but IMHO it's pointless because systemd supports sysvinit- style initscripts, and we won't get rid of all of them in the next years - even if there are "only" some external packages that still come with initscripts, we can't drop the backwards compatibility.

There is more documentation, than the old system ever had, including full grown how-tos to convert both units and daemons, example c code, libraries, tools, whatever..

Yes, but OTOH the old initscripts are plain shell code and therefore grep-able and somehow self-documenting. Additionally there's the usual (non)argument that everybody knows initscripts quite well, so nobody needs documentation. (I know that learning new things is part of the game, that's why I wrote "(non)argument" ;-) Sorry if this mail sounds like a flame, I'm probably influenced by the 4 flames on my advent wreath ;-)) Regards, Christian Boltz -- Eine "Sprache", in der man blubber schreiben muß, wo jeder andere foo(blubber) schreibt, *muß* irgendwie ein Erfolg werden. Jedenfalls für Festplatten- und Speicherverkäufer. [Stefan Reuther] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 17.12.2011 18:12, schrieb Cristian Rodríguez:

On 18/12/11 07:10, Wolfgang Rosenauer wrote:

...

might be that systemd is documented. What still is not very comprehensive though is packager documentation for openSUSE's systemd migration. http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines (this is simply not answering many questions)

http://en.opensuse.org/openSUSE:Systemd_status

I was able to find a solution/workaround for some of them. And I'm not sure if those break because I wasn't able to fully test them.

what is missing there so it can be improved ? do we want to duplicate the man pages or other documentation found in upstream ?

http://www.freedesktop.org/wiki/Software/systemd

I believe that's enough, at least is enough to get started for me :-)

You apparently neither have read this mail nor the status page. Most of the open questions I have are not systemd specific but openSUSE specific. We have no proper documentation how to migrate a package from init script to a systemd service and what macros are acceptable or how a package can be enabled by default without touching some base system package. I won't repeat the question on that page here but let me quote from a package where I tried to support systemd (on 12.1 with sysvinit and systemd support): %post %if %suse_version > 1140 %service_add_post pcscd.service pcscd.socket /bin/systemctl disable pcscd.service || : /bin/systemctl enable pcscd.socket || : /bin/systemctl try-restart pcscd.service || : /bin/systemctl restart pcscd.socket || : %endif %fillup_and_insserv -y -n pcscd pcscd %restart_on_update pcscd %postun %if %suse_version > 1140 %service_del_postun pcscd.service pcscd.socket # make sure to reload systemd for possible downgrades if [ "$1" = "1" ]; then /bin/systemctl daemon-reload >/dev/null 2>&1 || : fi %endif %insserv_cleanup I'm absolutely sure that something above is broken but as I said the packaging guidelines specific to openSUSE are more than lacking and upstream systemd documentation doesn't help with that. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2011/12/18 18:46 (GMT+0100) Wolfgang Rosenauer composed:

On 2011/12/17 14:12 (GMT-0300) Cristian Rodríguez composed:

...

On 2011/12/18 18:46 (GMT+0100) Wolfgang Rosenauer composed:

Anyone besides me have a problem with Cristian's competence/authority? He's been replying to posts from the future for at least two days now. I emptied my trash last night, but his most recently written posts there now were all written on 12/17 before 13:00 his time, before I emptied my trash. References: <4EEBBA35.8070304@opensuse.org> <4EECFE84.6040109@lsmod.de> <4EEBDFD0.2030002@opensuse.org> <4EEDBC0F.7030609@rosenauer.org> <4EECCD63.7080709@opensuse.org> In-Reply-To: <4EECCD63.7080709@opensuse.org> -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/18/2011 07:43 PM, Felix Miata wrote:

On 2011/12/18 18:46 (GMT+0100) Wolfgang Rosenauer composed:

...

On 2011/12/17 14:12 (GMT-0300) Cristian Rodríguez composed:

...

...

On 2011/12/18 18:46 (GMT+0100) Wolfgang Rosenauer composed:

Anyone besides me have a problem with Cristian's competence/authority? He's been replying to posts from the future for at least two days now. I emptied my trash last night, but his most recently written posts there now were all written on 12/17 before 13:00 his time, before I emptied my trash.

I guess, systemd does not start ntp on boot for him ;) or another systemd-related change hit him: https://bugzilla.redhat.com/show_bug.cgi?id=750883 It did not autostart postfix for me (until I manually enabled it), even though it was default-enabled on openSUSE for a long time. Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/17/2011 06:26 PM, Cristian Rodríguez wrote:

On 18/12/11 06:13, Bernhard M. Wiedemann wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Am 17.12.2011 01:18, schrieb Cristian Rodríguez:

...

On 17/12/11 17:41, Bernhard M. Wiedemann wrote:

...

https://bugzilla.novell.com/buglist.cgi?quicksearch=systemd

yes most of those are bugs elsewhere..

bugs that only occur because of systemd can not be ignored when you want to drop the working alternative.

If I dont' narrow down the proposal, the number of different scenarios go to the roof.

what do you count as a "scenario"? And what is bad about different scenarios?

...

let's have an example - I used to adapt the timeout for mounting my crypted home partition. By looking at /etc/init.d/boot.crypto I found that /lib/cryptsetup/boot.crypto.functions contains a TIMEOUT value of 120 seconds, which I then change with a text editor and will thus be used on next boot. Systemd does not use /etc/init.d/boot.* files

with "find" I found /lib/systemd/systemd-cryptsetup (binary - so unreadable)

Yes, that's because systemd interfaces with libcryptsetup ..

where is the advantage over LUKS cryptsetup?

and

...

/lib/systemd/system/cryptsetup.target

which mentions man 7 systemd.special but this manual page does not even mention "crypt" once. And nothing about "timeout" either.

Did you filled a bug report ?

if I always filed such things there would not just be 150 reports from me. And I would still like to know how to tune the timeout value. You said, there was a lot of documentation on systemd, so such a trivial thing should be covered, shouldn't it?

...

Where does the support effort come from (aside from fixing bugs that need fixing anyway)?

bit rotting.

And by supporting /etc/init.d and .service files we get more rotten bits? My /etc/init.d has just 18K lines. Not really much to maintain.

...

I can see some effort in maintaining /etc/init.d/boot.* files together with their systemd equivalent.

Some of them will probably go away as systemd handles them natively.

I thought, it already does handle all of them natively, because it does not run them.

...

are we in a hurry?

The sooner the better, people will eb able to direct efforts into one thing, that has ONE particular set of rules.

rules of bash scripts are already well known among admins, packagers and system-integrators - no "effort" to redirect there. Once systemd works as it should, and proves to be better than sysvinit, people will move towards it - so no need to force it upon us. Ciao Bernhard M. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, Dec 17, 2011 at 09:50:17PM +0100, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2011-12-17 18:24, Cristian Rodríguez wrote:

...

Third party packages cannot be fixed by opensuse neither we should stop doing things just because some other provider does not fix their stuff.(will fail on fedora, mandriva and other distros that are in this same boat too)

But they hurt users.

...

If we consider this argument then nothing will go forward, the number of usecase scenarios become unmanageable and will be forever stuck if we care about crap packages provided by someone else.

It pains me that you do not have pity on us users.

+1

Systemd has and will have a mechanism to execute old style init scripts. And I'm sure we'll keep this mechanism for quite some time. Also I don't see a reason why we should drop this. But the goal for openSUSE should be to deliver native systemd targets for all services. Thanks Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Sunday 18 December 2011, Lars Müller wrote:

On Sun, Dec 18, 2011 at 02:41:32AM +0100, Rüdiger Meier wrote: [ 8< ]

...

I would expect something like this:

------------ [...] Starting mail service (Postfix) done Starting CRON daemon done Starting smartd unused Master Resource Control: Running /etc/init.d/after.local done Master Resource Control: runlevel 3 has been reached Skipped services in runlevel 3: cpufreq microcode.ctl smartd

Welcome to openSUSE 12.1 "Asparagus" - Kernel 3.1.0-1.2-desktop (ttyS0).

This is possible if the scripts are executed in a linear way/ order. And even with sysvinit we set by default /etc/sysconfig/boot:RUN_PARALLEL="yes" which already caused some messages to get messed between others. You had been able to see this afterwards in /var/log/boot.msg

With systemd this all gets more agile, felxible, unsorted, out of order and therefore it doesn't make much sense to try to keep it in order.

I don't complain about the order. I can't login via serial console when using systemd. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez wrote:

...

On 18/12/11 11:12, Sid Boyce wrote:

...

...

I enabled apache2.service in /lib/systemd/system.preset/default-openSUSE.preset but that didn't fix ce

That for sure is the wrong place.

...

Success! There is an apache2.service file in /lib/systemd/system

...

# ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/ Now apache2 starts automatically on boot. Regards Sid.

SO, it is not a bug after all, you simple missed what systemctl enable apache2.service is all about...

I did same thing (just copied it from the post) with postfix in my 64 bit 12.1:

ln -s /lib/systemd/system/postfix.service /etc/systemd/system/multi-user.target.wants

and now it starts.

This is like great but how was I supposed to come up with this? How can anybody know about these things and is it really meant to be done this way?

I mean it's system mail that is supposed to be there like always?

Vahis It's quite a bit of a disappointment when services that automatically work with sysvinit do not get launched by systemd. When I found there was a apache2.service file and no symlink in /etc/systemd to match the other services I thought that must have been

On 18/12/11 17:27, Vahis wrote: the problem. I have the x86_64 laptop and another x86_64 box running systemd now and everything I looked at so far is OK. Just seeing if over the next days something else will come to light. When I first tried systemd there were problems with VirtualBox, apache2 and pulseaudio not starting automatically, so there have been improvements. No doubt much more needs to be done. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot, Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian Rodríguez writes:

On 17/12/11 07:38, Sid Boyce wrote:

...

It's frustrating to find after switching to systemd,

Which services do not start?

rpc.idmapd despite an explicit setting in /etc/sysconfig/nfs, see https://bugzilla.novell.com/show_bug.cgi?id=737553 Also rpc_pipefs is not mounted anymore, see https://bugzilla.novell.com/show_bug.cgi?id=737551 Auxiliary consoles are not supported anymore, ttyS0 here, see: https://bugzilla.novell.com/show_bug.cgi?id=737550 Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 17/12/11 16:49, Cristian Rodríguez wrote:

On 18/12/11 11:12, Sid Boyce wrote:

...

...

I enabled apache2.service in /lib/systemd/system.preset/default-openSUSE.preset but that didn't fix ce

That for sure is the wrong place.

...

Success! There is an apache2.service file in /lib/systemd/system

...

# ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/ Now apache2 starts automatically on boot. Regards Sid.

SO, it is not a bug after all, you simple missed what systemctl enable apache2.service is all about... It was a bug in that it wasn't automatically started as before and not a bug due to unfamiliarity with the foibles of systemd, not knowing there was a apache2.service - same thing accomplished via a different route. # systemctl enable apache2.service ln -s '/lib/systemd/system/apache2.service' '/etc/systemd/system/multi-user.target.wants/apache2.service' # Regards Sid.

-- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot, Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Saturday, December 17, 2011 18:12:26 Per Jessen wrote:

Cristian Rodríguez wrote:

...

Hi:

Supporting 2 different init systems comes with a large increase of possible usecases and scenarios that are very difficult to support correctly, specially in the long term.

This RFC proposes steps to permanently phase out sysvinit from future openSUSE releases.

I'm not sure where this belongs, but I think we should also consider what to do about third party products or packages that are unlikely to upgrade to systemd or where an upgrade is not expected before our first release without sysvinit support.

We should indeed keep the support for the LSB init scripts for third party packages. Any I suggest that the proposal adds that as clarification.

I know this is difficult, but people who are using third party products could list them. Examples I have myself - the HP Proliant Support Pack and 3ware init-scripts.

As long as they use LSB init scripts - and I guess they do - they should continue to work... 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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le dimanche 18 décembre 2011 à 20:12 +0100, Lars Müller a écrit :

On Sat, Dec 17, 2011 at 09:50:17PM +0100, Per Jessen wrote:

...

Carlos E. R. wrote:

...

On 2011-12-17 18:24, Cristian Rodríguez wrote:

...

Third party packages cannot be fixed by opensuse neither we should stop doing things just because some other provider does not fix their stuff.(will fail on fedora, mandriva and other distros that are in this same boat too)

But they hurt users.

...

If we consider this argument then nothing will go forward, the number of usecase scenarios become unmanageable and will be forever stuck if we care about crap packages provided by someone else.

It pains me that you do not have pity on us users.

+1

Systemd has and will have a mechanism to execute old style init scripts. And I'm sure we'll keep this mechanism for quite some time. Also I don't see a reason why we should drop this.

Exactly.. The support for sysv initscripts might be migrated to a systemd generator in the future (ie an implementation detail) but there is no plan to drop it at all.

But the goal for openSUSE should be to deliver native systemd targets for all services.

That was part of my original plan but we didn't reach it for 12.1. Let's see if we can improve this for 12.2. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 17.12.2011 18:54, schrieb Cristian Rodríguez:

...

ln -s /lib/systemd/system/postfix.service /etc/systemd/system/multi-user.target.wants

and now it starts.

You have to use systemctl enable postfix.service, the symlink is created as a result of that command.

...

This is like great but how was I supposed to come up with this?

man systemctl ?

see also my other mail: even old-fashioned "chkconfig postfix" would have told. However, there are obviously some bugs in the update process from sysv to systemd which lead to services being disabled which were not before. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Dec 18, 2011 at 10:34:11AM +0100, todd rme wrote:

There are teams who either volunteer or are payed to support different parts of openSUSE, such as the different desktop environments. If a group of systemv enthusiasts wants to step up and provide long-term support for systemv, as is currently being done e.g. with KDE3, I suspect this would be possible. The problem is trying to make the current team do two jobs when they already have enough trouble just doing one.

AFAICT not much effort has gone into sysvinit in the last years, so I don't see why you think it would be hard to maintain it. (Multiple years is probably out of the question, though. But the proposal makes it sound like sysvinit should be dropped for 12.2, which may be a bit too early.) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Frederic Crozat wrote:

Le dimanche 18 décembre 2011 à 20:12 +0100, Lars Müller a écrit : [...]

...

But the goal for openSUSE should be to deliver native systemd targets for all services.

That was part of my original plan but we didn't reach it for 12.1. Let's see if we can improve this for 12.2.

What's the benefit besides some people's obsession against shell scripts and intentionally breaking the sysv fallback? Fine to add systemd files for services where it makes a difference, e.g. socket activatable ones but for the majority there is no need to put effort into .service files IMO. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 19/12/11 10:26, Stefan Seyfried wrote:

Am 17.12.2011 18:54, schrieb Cristian Rodríguez:

...

...

ln -s /lib/systemd/system/postfix.service /etc/systemd/system/multi-user.target.wants

and now it starts. You have to use systemctl enable postfix.service, the symlink is created as a result of that command.

...

This is like great but how was I supposed to come up with this? man systemctl ?

see also my other mail: even old-fashioned "chkconfig postfix" would have told.

However, there are obviously some bugs in the update process from sysv to systemd which lead to services being disabled which were not before.

It's all part of a learning curve of which stumbling is a part of the early steps. With systemd replacing or superceding sysvinit I and I'm sure many othere expected it to be a seamless transition. What we had here was an incomplete duplication of the services automatically launched by systemd, i.e you see a service missing and then having to dig into lots of documentation to discover the reason. It would have been kinder to have provided a README or some such with what was supported and what was on the todo list. It needen't have been a long treatise but it would have helped in avoiding surprises. Even an pointer to the URL's given here in the last day or so would have forewarned and informed users better. If I were a sysadmin, I would consign systemd to a test machine until I was 100% certain it was a safe replacement for sysvinit - mid 2012 timeline perhaps. I suppose current users are performing the testing role and reporting back in an effort to highlight problems and misconceptions so they can be dealt with as surely they will be and systemd difficulties will melt away perhaps even much quicker than the massive and disruptive change to glibc if anyone can remember that far back. Upstart has caused similar though small ripples on Ubuntu. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot, Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, Am Samstag, 17. Dezember 2011 schrieb Cristian Rodríguez:

On 18/12/11 13:53, Christian Boltz wrote:

...

Now tell me how to do this in a *.service file without using a script (extremely simplified version of loading the AppArmor profiles):

ls -1 /etc/apparmor.d/ | grep -v 'rpmnew$\|rpmold$' | \ while read profile ; do apparmor_parser "/etc/apparmor.d/$profile" done

I guess apparmor_parser can by itself exclude backup files and provide recursion no ?

AFAIK it can't - the current initscript loads one profile after the other. It might sound like a disadvantage, but OTOH it allows to selectively load or reload a single profile manually. To name another example: check the current (quite verbose) output of "rcapparmor status". How can this (running the "aa-status" command) be done with systemd when someone checks the status? I know about ExecStart, ExecReload and ExecStop, but I don't see something like ExecStatus in systemd.service(5). You probably know that there is nothing like a permanently running AppArmor process, so looking up the status somewhere in the process table ("is the started process still running?") is impossible. I allso don't like the idea to rely on "we loaded the profiles, so they must still be there" because someone could have unloaded them manually. Back to my question - how can this be handled in a *.service file?

...

Yes, but OTOH the old initscripts are plain shell code and therefore grep-able and somehow self-documenting.

no, they are not.

We could make that a shout match - "yes, they are!" [1] - but let's get back to the more constructive part of the discussion ;-) Regards, Christian Boltz [1] I listed several arguments in my previous mail, no need to repeat them here ;-) -- Lass es mich so sagen: GUIs? Wir haben keine. Davon aber zwei. [Ratti in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/17/2011 12:12 PM, Per Jessen wrote:

Cristian Rodríguez wrote:

...

Hi:

Supporting 2 different init systems comes with a large increase of possible usecases and scenarios that are very difficult to support correctly, specially in the long term.

This RFC proposes steps to permanently phase out sysvinit from future openSUSE releases.

I'm not sure where this belongs, but I think we should also consider what to do about third party products or packages that are unlikely to upgrade to systemd or where an upgrade is not expected before our first release without sysvinit support. I know this is difficult, but people who are using third party products could list them. Examples I have myself - the HP Proliant Support Pack and 3ware init-scripts.

Rand McNally Mile-Maker PC-Miler LSI raid cards Adaptec raid cards Equinox network serial port server Digi network serial port server Cyclades network serial port server VSI-FAX FacetWin (both the terminal emulator server and the file & print sharing server) eicon DIVA server I didn't ask for systemd, yet unless I want to be on an unsupported version of opensuse in a very few months, I suddenly have to take on the burden of updating or working around or reinventing the install and init scripts for all of those, some of which are no longer supported at all by the manufacturers even in the cases where the manufacturer still exists. That's by far not an exhaustive list of course, probably not even complete just for my singular self. And if I don't go through the significant time and hardware consuming steps to test and fully document the problems with each of those, it's my fault. Thanks. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Dec 19, 2011 at 03:52:02PM -0500, Brian K. White wrote: [ 8< ]

It's not in your own interests to keep rebuffing user complaints.

Right.

At the very very least, you could say "We apologize, we know it sucks right now. We need help making a major transition. We are sorry for making these changes which broke all your stuff. We should not have released this yet." That at least will gain you some percentage of sympathy. And at least some percentage of users will decide to give you their time and effort to submit proper bugzilla entries with better documented observations.

Cristian expressed his point of view. In the past he had himself been very, very critical towards systemd too. Unfortunately systemd testing while the development of openSUSE 12.1 didn't got the same attention as it got with or after the release. As soon as we got aware which amount of trouble it caused we took action and filed http://en.openSUSE.org/openSUSE:Most_annoying_bugs_12.1 section 'Problem: System is switched from sysvinit to systemd during upgrade.'. This at least offers and easy way to switch back to sysvinit. Unfortunately after the release there is no real alternative to handle this better. The only alternative which comes to my mind is to publish an update which forces all users back. I'm sure this action would at the end cause additional and even more confusion. Therefore the main goal at the moment is to get the outstanding updated published. @Frederic: Am I get it right and the upcoming update is this one? https://build.opensuse.org/project/show?project=openSUSE%3AMaintenance%3A126 To let us all focus on the enhancement I'm telling all people bitten by the beast I'm very, very sorry and hope we'll all will make a better job with openSUSE 12.2. Thanks Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Monday 19 December 2011, Lars Müller wrote:

On Mon, Dec 19, 2011 at 03:52:02PM -0500, Brian K. White wrote: [ 8< ]

...

It's not in your own interests to keep rebuffing user complaints.

Right.

...

At the very very least, you could say "We apologize, we know it sucks right now. We need help making a major transition. We are sorry for making these changes which broke all your stuff. We should not have released this yet." That at least will gain you some percentage of sympathy. And at least some percentage of users will decide to give you their time and effort to submit proper bugzilla entries with better documented observations.

Cristian expressed his point of view. In the past he had himself been very, very critical towards systemd too.

Unfortunately systemd testing while the development of openSUSE 12.1 didn't got the same attention as it got with or after the release.

Thats natural. Usually I'm testing stuff which is interesting to me. Systemd or any other boot stuff is not. All my machines are 24/7 online. If I have to reboot after months uptime (power failure or kernel updates) I expect it to work or at least being able to debug it easily (either thanks to well known transparent shell scripts for example or complete documentation/release notes if something fundamental has been changed lately). Even sysvinit's starpar patches (11.x?) made me horrible surprises so I disabled that everywhere since I've noticed it first time. I would not even write bug reports about it because I don't need it fixed. The fact that we've had too less systemd testers/bug reporters is pity, but IMO it should have been pity only for the ones who want sytemd into openSUSE. I find it strange that there was no sensiblity to suspend default systemd to 12.2.

As soon as we got aware which amount of trouble it caused we took action and filed http://en.openSUSE.org/openSUSE:Most_annoying_bugs_12.1 section 'Problem: System is switched from sysvinit to systemd during upgrade.'. This at least offers and easy way to switch back to sysvinit.

This bug report (725917) is a good example to see how unsensible things got handled. There was enough time to fix that before releasing 12.1...

Unfortunately after the release there is no real alternative to handle this better. The only alternative which comes to my mind is to publish an update which forces all users back. I'm sure this action would at the end cause additional and even more confusion.

Therefore the main goal at the moment is to get the outstanding updated published.

@Frederic: Am I get it right and the upcoming update is this one? https://build.opensuse.org/project/show?project=openSUSE%3AMaintenanc e%3A126

To let us all focus on the enhancement I'm telling all people bitten by the beast I'm very, very sorry and hope we'll all will make a better job with openSUSE 12.2.

Yup, actually I've skipped 12.1 until now because all my test machines failed on basic things. And don't tell me "Have you filed a bug?" (see above). Back to the topic of this thread. I don't like most of Christian's proposal but of course the thing can't be as is currently. IMO first we should drop the F5 button in grub as soon as possible and make systemd and sysvinit conflicting packages. Switching between sysvinit and systemd should be possible only using rpm/zypper. This way the systemd supporters would have it already a lot easier because on installations where systemd resides they have not to care about sysvinit stuff. Going this way we could drop either sysvinit or systemd easily at any time in future. If I find time next days I will try to write down more exactly how I would do it and also some pros and cons about that way. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 19/12/11 19:53, Lars Müller wrote:

Cristian expressed his point of view. In the past he had himself been very, very critical towards systemd too.

Well, yeah, but now, even when it doesn't handle some cases correctly yet and there are bugs elsewhere too,it is in an state where we can move forward.

To let us all focus on the enhancement I'm telling all people bitten by the beast I'm very, very sorry and hope we'll all will make a better job with openSUSE 12.2.

This is one of the effects of this proposal, we focus in one way to do things, make it handle the few cases it does not and this issue will go away. Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le lundi 19 décembre 2011 à 21:20 +0100, Christian Boltz a écrit :

Hello,

Am Samstag, 17. Dezember 2011 schrieb Cristian Rodríguez:

...

On 18/12/11 13:53, Christian Boltz wrote:

...

Now tell me how to do this in a *.service file without using a script (extremely simplified version of loading the AppArmor profiles):

ls -1 /etc/apparmor.d/ | grep -v 'rpmnew$\|rpmold$' | \ while read profile ; do apparmor_parser "/etc/apparmor.d/$profile" done

I guess apparmor_parser can by itself exclude backup files and provide recursion no ?

AFAIK it can't - the current initscript loads one profile after the other. It might sound like a disadvantage, but OTOH it allows to selectively load or reload a single profile manually.

To name another example: check the current (quite verbose) output of "rcapparmor status". How can this (running the "aa-status" command) be done with systemd when someone checks the status? I know about ExecStart, ExecReload and ExecStop, but I don't see something like ExecStatus in systemd.service(5).

You probably know that there is nothing like a permanently running AppArmor process, so looking up the status somewhere in the process table ("is the started process still running?") is impossible. I allso don't like the idea to rely on "we loaded the profiles, so they must still be there" because someone could have unloaded them manually.

Back to my question - how can this be handled in a *.service file?

It can't. systemctl status foo.service is supposed to return an errorcode (and some systemd text output), in a standard form and that's it. rc* SUSE-ish shouldn't rely on initscript "status" command to output anything but the "standard" form. Additional commands should be used instead. See http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Dec 19, 2011 at 05:42:39PM -0800, Linda Walsh wrote: [ 8< ]

Having filed a bunch of bugs only to find most of them unfixed years later, is not exactly encouraging of filing bugs...

This is only one half of the story. Unfortunately many bugs stay assigned to the default assignee even if a bug owner for a particular package is defined in the Open Build Service. Unfortunately it still requires some extra work to get the default bug owner via a call to the osc tool. Therefore we as the community have to blame a bit ourself if we're not able to learn and drive issues better. Thanks Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On Fri, Dec 16, 2011 at 11:10 AM, Cristian Rodríguez wrote:

Bug numbers ? note that bugs in other components have nothing to do with systemd.

It may have nothing to do with systemd, but has all to do with the ability to switch to it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Dec 20, 2011 at 7:29 AM, Claudio Freire wrote:

On Fri, Dec 16, 2011 at 11:10 AM, Cristian Rodríguez wrote:

...

Bug numbers ? note that bugs in other components have nothing to do with systemd.

It may have nothing to do with systemd, but has all to do with the ability to switch to it.

In the linux kernel, Linus has imposed a rule that if you add or change code that causes pre-existing code to fail, then you are responsible for making sure the issues are resolved before your work is accepted into the kernel. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Greg Freemyer wrote:

On Tue, Dec 20, 2011 at 7:29 AM, Claudio Freire wrote:

...

On Fri, Dec 16, 2011 at 11:10 AM, Cristian Rodríguez wrote:

...

Bug numbers ? note that bugs in other components have nothing to do with systemd.

It may have nothing to do with systemd, but has all to do with the ability to switch to it.

In the linux kernel, Linus has imposed a rule that if you add or change code that causes pre-existing code to fail, then you are responsible for making sure the issues are resolved before your work is accepted into the kernel.

Sounds fair and solid to me. Since one can't do much with just the kernel additional stuff like a system(d) to boot things is needed. One could almost think that those go so much together that one should apply that rule? I'm also wondering,when some updates could be expected. I updated the other day to systemd-37-317.1.x86_64 and with that I have system mail. But 'zypper up' still wants to downgrade from official updates. Maybe something is in progress and official update is not finished yet? Vahis -- openSUSE 11.4 (x86_64) 2.6.37.6-0.9-default main host openSUSE 12.1 (x86_64) 3.1.1-48-desktop Tumbleweed in VirtualBox openSUSE 12.1 (i586) 3.1.0-1.2-desktop in EeePC 900 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mardi 20 décembre 2011 à 16:05 +0100, Christian Boltz a écrit :

Hello,

Am Dienstag, 20. Dezember 2011 schrieb Frederic Crozat:

...

Le lundi 19 décembre 2011 à 21:20 +0100, Christian Boltz a écrit :

...

Am Samstag, 17. Dezember 2011 schrieb Cristian Rodríguez:

...

On 18/12/11 13:53, Christian Boltz wrote: To name another example: check the current (quite verbose) output of "rcapparmor status". How can this (running the "aa-status" command) be done with systemd when someone checks the status? I know about ExecStart, ExecReload and ExecStop, but I don't see something like ExecStatus in systemd.service(5).

You probably know that there is nothing like a permanently running AppArmor process, so looking up the status somewhere in the process table ("is the started process still running?") is impossible. I allso don't like the idea to rely on "we loaded the profiles, so they must still be there" because someone could have unloaded them manually.

Back to my question - how can this be handled in a *.service file?

It can't. systemctl status foo.service is supposed to return an errorcode (and some systemd text output), in a standard form and that's it.

That's a clear answer. Not my favorite one, but thanks nevertheless.

...

rc* SUSE-ish shouldn't rely on initscript "status" command to output anything but the "standard" form.

OK, but I still have a problem - how can systemd detect the status of AppArmor?

There's no running process systemd could detect.

Such services (like apparmor, SUSEfirewall, cpufreq) are considered as systemd as "RemainAfterExit" (cf man systemd.service) : they will look as "active" (ie running) service after the startup, not relying on a process to keep running However, when not using .service where you can specify RemainAfterExit explicitly (ie when using initscript), we had to create a heuristic to try to guess if an initscript is a service which is starting a daemon or not (to detect properly if not having anything left running for this service is a failure or not). This heuristic is not perfect (unfortunately), so, we added two additional LSB like headers to be used for initscripts (it will be present in the pending maintenance update): # PIDFile: (this one is modeled after RH / Fedora initscript header) You specify the path of the PID file of the service and systemd will use it to detect if the service is active and running properly (instead of relying on heuristic to guess daemon PID and to detect when nothing else is running). Having this header implies RemainAfterExit will be set to "no" by systemd. # X-Systemd-RemainAfterExit: Just like for a .service, it allows to tell systemd an initscript doesn't start any daemon and therefore, it shouldn't consider no daemon running is a failure.

The initscript calls "aa-status", prints its output and returns the status/errorcode based on $? of aa-status. How can I do this (execute a command when checking the status) with systemd to get at least the errorcode?

You can't, through systemd. The service will be based on either it is running (for a RemainAfterExit=false type) or it was run based on its error code (for a RemainAfterExit=true type). -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 20 December 2011, Dimstar / Dominique Leuenberger wrote:

On Tue, 2011-12-20 at 09:33 -0500, Greg Freemyer wrote:

...

In the linux kernel, Linus has imposed a rule that if you add or change code that causes pre-existing code to fail, then you are responsible for making sure the issues are resolved before your work is accepted into the kernel.

This is 100% limited on the 'internal code' of the kernel... Which is also the case for systemd: if you change the code, the internally needed modifications are to be done by you.

To complete your analogy with the kernel: 3rd party modules can break with every single update or RC-release... nobody from the kernel maintainers will care. And as such: the analogy does not make sense.

On this list we are 100% openSUSE internal. If kernel 3.x breaks fundamental things in openSUSe then things needs too be fixed before releasing the kernel package update. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hello, Am Dienstag, 20. Dezember 2011 schrieb Frederic Crozat:

Le mardi 20 décembre 2011 à 16:05 +0100, Christian Boltz a écrit :

...

The initscript calls "aa-status", prints its output and returns the status/errorcode based on $? of aa-status. How can I do this (execute a command when checking the status) with systemd to get at least the errorcode?

You can't, through systemd. The service will be based on either it is running (for a RemainAfterExit=false type) or it was run based on its error code (for a RemainAfterExit=true type).

In other words: when I ask for the status it says "well, I started it, so it must still be active" - right? I'm sorry, but just _assuming_ the status instead of _checking_ it sounds like a bad idea[tm]. It's even worse because we are talking about security-relevant services (AppArmor, SuSEfirewall) here - I'd prefer to get the real status instead of a "well, I started it..." ;-) Please consider to implement something like ExecStatus=/path/to/status-checking-binary in *.service files to fix this issue. Regards, Christian Boltz -- Und als nächste dürfen Querschnittgelähmte spammen, Blinde dürfen meinen Server aufmachen, und wer als Kind im Ostblock aufgewachsen ist darf HTML-Mails schreiben? Super. Ich hatte mal Mittelohrentzündung, das sollte reichen, um Outlook benutzen zu dürfen? [Ratti in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-12-17 18:24, Cristian Rodríguez wrote:

...

Third party packages cannot be fixed by opensuse neither we should stop doing things just because some other provider does not fix their stuff.(will fail on fedora, mandriva and other distros that are in this same boat too)

But they hurt users.

...

If we consider this argument then nothing will go forward, the number of usecase scenarios become unmanageable and will be forever stuck if we care about crap packages provided by someone else.

It pains me that you do not have pity on us users.

+ 10,000 Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mardi 20 décembre 2011 à 20:21 +0100, Christian Boltz a écrit :

Hello,

Am Dienstag, 20. Dezember 2011 schrieb Frederic Crozat:

...

Le mardi 20 décembre 2011 à 16:05 +0100, Christian Boltz a écrit :

...

The initscript calls "aa-status", prints its output and returns the status/errorcode based on $? of aa-status. How can I do this (execute a command when checking the status) with systemd to get at least the errorcode?

You can't, through systemd. The service will be based on either it is running (for a RemainAfterExit=false type) or it was run based on its error code (for a RemainAfterExit=true type).

In other words: when I ask for the status it says "well, I started it, so it must still be active" - right?

I'm sorry, but just _assuming_ the status instead of _checking_ it sounds like a bad idea[tm]. It's even worse because we are talking about security-relevant services (AppArmor, SuSEfirewall) here - I'd prefer to get the real status instead of a "well, I started it..." ;-)

Well, either there is a daemon running and the check is working fine, either there isn't and the service isn't a "real" service. It was just faked.

Please consider to implement something like ExecStatus=/path/to/status-checking-binary in *.service files to fix this issue.

Please raise this topic upstream directly, since you are advocating for it. -- Frederic Crozat SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Dec 21, 2011 at 5:31 AM, Frederic Crozat wrote:

...

I'm sorry, but just _assuming_ the status instead of _checking_ it sounds like a bad idea[tm]. It's even worse because we are talking about security-relevant services (AppArmor, SuSEfirewall) here - I'd prefer to get the real status instead of a "well, I started it..." ;-)

Well, either there is a daemon running and the check is working fine, either there isn't and the service isn't a "real" service. It was just faked.

Assuming a service is a daemon is quite shortsighted. Not to mention dumb. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Dec 22, 2011 at 09:30:36AM +0100, Bernhard M. Wiedemann wrote:

On 12/20/2011 01:06 PM, Lars Müller wrote:

...

On Mon, Dec 19, 2011 at 05:42:39PM -0800, Linda Walsh wrote: [ 8< ]

...

Having filed a bunch of bugs only to find most of them unfixed years later, is not exactly encouraging of filing bugs...

This is only one half of the story. Unfortunately many bugs stay assigned to the default assignee even if a bug owner for a particular package is defined in the Open Build Service.

Unfortunately it still requires some extra work to get the default bug owner via a call to the osc tool.

I made a CGI to make this easier for me - e.g. for systemd you look at http://aw.lsmod.de/cgi-bin/public/opensusemaintainer/systemd

Source: http://aw.lsmod.de/code/perl/opensusemaintainer

Dude, cool! I like to see something like this intergrated with bugzilla and being able to display the bug owner if defined for a project. Hm, looks like your tool is doing this corretly already. Only the lame guys of network:samba:STABLE have not defined a bug owner. Lame, lame, lame. :/ Time to brew coffee and to get up a bit more. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

On 20/12/11 09:51, Claudio Freire wrote:

On Sat, Dec 17, 2011 at 2:33 PM, Cristian Rodríguez wrote:

...

...

Ignoring timeframe, I'm not aware that either of those are goals. I

have seen it posted repeatedly that systemd supports scripts in /etc/init.d, so it is not obvious to me that your assumed goals are in fact opensuse community goals.

If this is not a goal, then goals are wrong and plain madness.

This sounds like newitis to me.

This sound like an appeal to tradition to me.

If an init script does its job... why not use it?

if you want to use an init script it should work, my proposal is addressed at packages included in the main distribution, not third party or custom scripts. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Dec 25, 2011 at 2:16 PM, Cristian Rodríguez wrote:

-either daemon running or not. - some script returning an standard code to tell if it is loaded or not

everything else is guessing, I hope we agree we should not be in the magic & incantation business ;-)

You've been given examples of services that aren't either daemons or where a "standard code" is an oversimplification. If you ignore it, there's no much point in issuing an RFC I guess. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sun, Dec 25, 2011 at 7:50 PM, Graham Anderson wrote:

On Sunday 25 Dec 2011 15:52:47 Claudio Freire wrote:

...

You've been given examples of services that aren't either daemons or where a "standard code" is an oversimplification.

I reject the premise of this argument. AppArmor is implemented as kernel code and as such is pretty much the definition of a daemonised service. That the profiles are injected sequentially via scripts is probably in itself more a clue about AppArmors design than anything else.

So what? Does that make it pointless to query AppArmor's status? Does the fact that its status depends on which profiles are loaded is immaterial? Does that design make it irrelevant to know which profiles are laded when querying status? I say if you say "No" to any of those questions, you're just shooting yourself in the foot. If it were pointless to query AppArmor's status, then it's pointless to have it. Many servers run 365/24/7, and that means there's lots of ways in which profiles can be unloaded and a reboot is not an option. If you "just assume it's running" because "I started it", then you're simply wrong. Querying status here is an important sysadmin tool. Same applies to knowing which profiles have been loaded. One profile being unloaded isn't the same as the whole service being down, so it's an important distinction.

...

If you ignore it, there's no much point in issuing an RFC I guess.

RFC is not "tell me every little detail you want included". It's a polite way of hearing arguements. *Any and all* of which *may and can* be ignored, excluded, argued against of even ridiculed.

The point of an RFC is hearing arguments. The OP doesn't seem to be hearing.

The _request for comments_ has highlighted one area where systemd doesn't seem to have a remit or functionality to deal with. I would argue that this is more a problem of AppArmor using sysvinit as convenience than anything that systemd should even be concerned with.

The RFC has already at least one sysadmin commenting on how that "convenience" is good. I can subscribe to that. If the OP ignores this, because systemd doesn't have the functionality and we *must* switch to systemd, then I say it's a backwards proposition. systemd has to serve sysadmins, not the other way around. So, you say it's an issue with AppArmor (and all other services that do so, like VMs, postgres, and who knows how many more). I say it's an issue with systemd, it's not functional enough to replace systemv yet. It's a simple functionality. It's just capturing the output of initscripts, and allowing native modules to produce output. I don't think it's so much to ask. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/25/2011 05:26 PM, Cristian Rodríguez wrote:

On 25/12/11 19:50, Graham Anderson wrote:

...

I would argue that this is more a problem of AppArmor

Yes, that's it. apparmor has to provide a way to know if it is loaded or not, not some shell script guessing...

Exactly. I was a skeptic initially about systemd, based on my experience with pulseaudio. I'm still quite allergic to having pulse on my system. That said, knowing Frederic, I knew openSUSE was going to have a very competent developer/packager handling this. Recently, at work I've been working fixing a number of broken/inconsistent initscripts as well as using systemd on 12.2. Yes, SysV initscript have been around a long time, but they are certainly not perfect and in some cases can be damn fussy, fragile and not fun to maintain. While there are some issues to be fixed, I am totally convinced systemd is the way forward. Having a single set of cross-distro system management tools is a very worthwhile and useful way of making Linux more flexible in the future. systemd files are simple. No more need to have separate debian/suse/fedora versions. I liken it going from auto* to cmake. Simpler, cleaner - sane error messages. Cheers, Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 03:28, Claudio Freire wrote:

Well, unless I'm mistaken about its capabilities.

Well, you are mistaken .

Really, missing an ExecStatus command is a big thing. ExecKill comes next.

What for ? ExecStart does account the exit status, ExecKill makes no sense.. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 12:59, Claudio Freire wrote:

Suppose something's wrong and ExecStop (which will try a graceful shut down of the VMs) doesn't work. Then you have to forcibly stop the VMs. How would systemd do it?

It will send SIGKILL to the process mentioned in ExecStart -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 13:33, Claudio Freire wrote:

On Mon, Dec 26, 2011 at 1:04 PM, Cristian Rodríguez wrote:

...

...

Suppose something's wrong and ExecStop (which will try a graceful shut down of the VMs)

doesn't work. Then you have to forcibly stop the VMs.

...

How would systemd do it?

It will send SIGKILL to the process mentioned in ExecStart

Which no longer exists, because it was a TSR that just started the VM with some command to the kernel. IE: totally wrong action to take.

there is a SendSIGKILL boolean to avoid that KillSignal to select what signal to use KillMode to select how the process should be killed if there is no process running and no Execstop script that can tell if it is running or not, then there is problem somewhere else. It needs to be that way, it is a true dichotomy. - It is either running or not - It is either loaded or it failed to. No half loaded or half running. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 26/12/11 14:09, Claudio Freire wrote:

On Mon, Dec 26, 2011 at 2:04 PM, Cristian Rodríguez wrote:

...

if there is no process running and no Execstop script that can tell if it is running or not, then there is problem somewhere else.

ExecStop is a graceful stop. ExecKill would be a forced stop.

ExecStop, when not present, attempts to do "graceful stop" (SIGTERM) first, if that does not work it sends "SIGKILL". if present, it executes the program mentioned in the variable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 12/26/2011 11:04 AM, Cristian Rodríguez wrote:

On 26/12/11 12:59, Claudio Freire wrote:

...

Suppose something's wrong and ExecStop (which will try a graceful shut down of the VMs) doesn't work. Then you have to forcibly stop the VMs. How would systemd do it?

It will send SIGKILL to the process mentioned in ExecStart

What process? There is not always any such thing as a process that implements the "service". And yet there IS a "service" and it has to be "started" and it has to be "stopped" _gracefully_ and there IS a "status". And these are all done by combinations of things to do and to check that results in the overall action and the testing if the overall action has happened or not, gracefully or not, in-progress or not. ExecStart in the LXC container vm example would be a script that would scan a directory of config files, and depending on their contents, possibly launch a few processes for each configured VM. Those processes might be anything. They might be a screen session which runs lxc-start which runs /sbin/init inside the container, leaving behind only the screen process and the init process and whatever the init process started. They might be a single sshd process, no screen, no init. they might be anything. But in all cases the parent script that launched all the vm processes is gone immediately as soon as the last configured vm is started. In this example there are processes that you can search for at shutdown time, but they are unpredictable. You must run a script that searches for them and deals with any that are found. It's not as unreliable as it sounds because although they are unpredictable because they are user configurable vs fixed, the config files can be read and there are tools to show the status of all LXC containers even if they were manually started without the normal configs and init script. So at query-time, there IS a meaningful and reliable answer to get, by running a script. And at shutdown time there IS a proper graceful way to shutdown and it too is by running a script. There is NO parent daemon that runs the whole time and manages all vm's other than the kernel itself. As I said before, a watchdog daemon could be written that would do all the same stuff ina perpetual loop, and that would then end up being something systemd could watch the way it expectes to. But why should we have to either write such a thing in the first place, or have it running 24/7 on the system just to satisfy systemd? This isn't one of those cases where systemd can claim "Well even though it worked for decades the service was always broken so you should fix it anyways and then it will work with systemd also just as a natural consequence of fixing your broken service." The service is already just fine, and it would be simply systemd dictating that the service do something extra that it doesn't need for no other purpose than to allow systemd to avoid having to do something to handle situations that exist, that it doesn't want to acknowledge. Any such watchdog would just be a downgrade in the overall system efficiency, reliability, predictability. You need ExecStatus -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-12-18 10:34, todd rme wrote:

What you are suggesting is more like demanding the KDE team support KDE 4 and KDE 3 long-term. That is not feasible in practice, since it would require they essentially support two entirely independent desktop environments. That is why support for KDE 3 has fallen to a different team that actually still has an interest in it. So the people who have an interest in systemv should step up and offer to support it long-term. That doesn't actually affect this proposal, though, since the main team will still need to transition to systemd just like the main KDE team transitioned to KDE 4 and the main Gnome team transitioned to Gnome 3.

My objection - and I suppose that of others - is not that systemV disappears, but that it disappears now. I think the move can not be done till systemD can prove it is worthy of it, all problems solved. Be it 12.2 or 15.1 - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk8DpU4ACgkQja8UbcUWM1wgLwD/TM2nnM/mHnQuurOFUdmLwVKk ftTPayz0cANYp85XaqUBAIBauNy64MZgoq15KGvXBMmsbP8SLZXAsa6vjQS7j7Vy =95+O -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Cristian et al, I am concerned about the adoption of systemd instead of sysvinit as OpenSuSE init and particularly concerned about the suggestion of phasing sysvinit out entirely. I think this would be a mistake at this time. Long-term Linux developers are surely entirely familiar with the setup of Linux. They are probably entirely familiar with installing development tools, downloading Kernel source through git, perhaps making changes to the source, compiling the amended source, copying the image into the relevant boot directory (different on OS n'est pas?), making changes to grub.conf (say), preparing their own initramfs etc. Then changing init scripts through bash and getting those scripts to run in the relevant runlevels. It is an everyday thing... done in the blink of an eye. Consider, however, the situation of somebody who has not begun to program in C - let alone begun to understand Linux architecture. They know there are programs running, they know there is a kernel that boots the machine, they know that is probably the first thing to run. But they really have no clue where to start beginning to understand how Linux actually works. But they are eager to join the merry band of programmers - they hanker to develop for the Kernel - one day... one day... Where to start?? So they pick up a book on Linux - generic Linux mind - not a specific OpenSuSE Linux. There must be something in this book that will tell me how my machine starts... So they open a book...I'll give you a short list of books: 1) How Linux Works: (Ward - No Starch Press): Chapter 3, Page 52++ "How Linux Boots"... Page 54 "The Init Process" 2) Linux Command Line and Shell Scripting Bible (Blum - John Wiley Press): Chapter 1: Pages 7-9: "The kernel creates the first process, the init process..." 3) Linux In A Nutshell (Siever, Weber, Figgins, Love & Robbins - O'Reilly Press - 5th Edition): Page 214 "init - System administration command... usually run from the boot loader". 4) Linux Professional Institute LPIC-1 Study Guide (Roderick W. Smith - Sybex press): Chapter 5: Page 234 "The Boot Process - point 5... Once the Linux kernel takes over... finally loading.... /sbin/init". 5) Understanding the Linux Kernel (Bovet & Cesati - O'Reilly Press): Chapter 1: An Overview of Unix Kernels Page 29: "The solution lies in a special system process called init..." 6) Beginning Linux Programming (Matthew & Stone - Wrox Press - 3rd Edition): Page 797 "init (where it all begins)" 7) Professional Assembly Language (Blum - Wrox Press): Chapter 12 - Using Linux System Calls ".... The kernel creates the first process, called the init process, to start all other processes...". Has anybody written a book for the beginner programmer to explain how OpenSuSE booting with SYSTEMD differs markedly from all those Linux books that are on sale describing SysVInit? Personally I don't like the idea of one process seeking to do so many things - it looks a bit like a Windows machine to me ("Here's a desktop. Live with it"). However, I can understand that it may be the way forward for some Linux developers/users. My concern is that if OpenSuSE drop support for SysVInit before there are adequate descriptions of SYSTEMD in programmers books, then I expect future programmers will develop for Gentoo, Arch etc. rather than OpenSuSE. You create a barrier with those who aim to develop in future. I am gradually moving to Gentoo before developing a full-blown "Linux From Scratch" system. SYSTEMD ain't for me (yet... perhaps never). OpenSuSE is getting a little monolithic to be honest and the support cycle ever shorter (11.3 already deprecated!). Finally, Lennart Poettering's attitude to other developers is frankly quite abusive - and I think that too is likely to see somebody else develop a better alternative to SYSTEMD.. So, don't burn your bridges just yet ;-) Mike P.S. I apologise for the length of this first post. Best regards to all. P.P.S. Yes it is a "Think of the children..." post. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 02/05/2012 12:58 AM, Michael Davies wrote:

I am concerned about the adoption of systemd instead of sysvinit as OpenSuSE init and particularly concerned about the suggestion of phasing sysvinit out entirely. I think this would be a mistake at this time.

The "bottom line" is that SystemV will only be kept if someone agrees to maintain it, AND does the job. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/02/12 03:46, Michael Davies wrote:

1) How Linux Works: (Ward - No Starch Press): Chapter 3, Page 52++ "How Linux Boots"... Page 54 "The Init Process"

what of the many different "init process" is documented, fedora,debian, opensuse ..etc all use different init systems.

Has anybody written a book for the beginner programmer to explain how OpenSuSE booting with SYSTEMD differs markedly from all those Linux

http://www.freedesktop.org/wiki/Software/systemd

Personally I don't like the idea of one process seeking to do so many things -

who told you that ? systemd does not do all its work in PID 1.. it has aux processes for that.

My concern is that if OpenSuSE drop support for SysVInit before there are adequate descriptions of SYSTEMD in programmers books.

Does any of those books describe the suse boot process ? hint, it is not the same of fedora, ubuntu,debian etc,,

then I expect future programmers will develop for Gentoo, Arch etc. rather than OpenSuSE.

That is non-sense.

You create a barrier with those who aim to develop in future.

No.

Finally, Lennart Poettering's attitude to other developers is frankly quite abusive -

See, this is what criticism of systemd is all about, personal attacks, same thing about the /usr merge. and I think that too is likely to see somebody else

develop a better alternative to SYSTEMD..

I personally don't think so. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 05 February 2012, Cristian Rodríguez wrote:

On 05/02/12 03:46, Michael Davies wrote:

...

You create a barrier with those who aim to develop in future.

No.

...

Finally, Lennart Poettering's attitude to other developers is frankly quite abusive -

See, this is what criticism of systemd is all about, personal attacks, same thing about the /usr merge.

Yes it's a personal attack. But he deserves it. Why the hell should I not blame him if I don't like what he's doing? Why Poettering is developing on posix/gnu/linux/distros at all? Because it's good old 70's transparent stuff. The stuff he doesn't like... The fact that we have these standards, easy concepts, shell scripts, etc. is the only fact why he is even able to develop his crap. The next Lennart after this Poettering will have a hard job to change anything ... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org