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.
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.
On 17/12/11 17:41, Bernhard M. Wiedemann wrote:
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)
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.
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 ?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2011-12-16 at 18:37 -0300, Cristian Rodríguez 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, the track record is awful.
- -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
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..
On Saturday 17 December 2011 01:59:39 Carlos E. R. wrote:
On Friday, 2011-12-16 at 18:37 -0300, Cristian Rodríguez 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, the track record is awful.
+1
it is still alpha qyality right now
Pete
On 17/12/11 08:20, Peter Nikolic wrote:
On Saturday 17 December 2011 01:59:39 Carlos E. R. wrote:
On Friday, 2011-12-16 at 18:37 -0300, Cristian Rodríguez 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, 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.
Am Samstag, 17. Dezember 2011, 02:59:39 schrieb Carlos E. R.:
On Friday, 2011-12-16 at 18:37 -0300, Cristian Rodríguez 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, the track record is awful.
Read all of the the proposal. Fixing the bugs is part oft the process.
Clearly there is much to fix here. Had to disable systemd on two machines myself.
Herbert
-----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)
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
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?
Here at least postfix, no system mail.
I am able to start it via YaST > System > Runlevels.
There it says that network needs to started and starts both and says the changes are saved..
Then it seems to run till next boot.
Same thing with all my 12.1 systems, 32 and 64 bit, virtual and real HW.
But this is on 12.1 so I'm OT with this on this list.
Vahis
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.
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?
Not a service, but still an important bug that must be fixed before any talk of phasing out sysvinit:
https://bugzilla.novell.com/show_bug.cgi?id=732353 "Missing output from init-scripts"
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.
On 12/17/2011 10:29 AM, Vahis wrote:
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?
Here at least postfix, no system mail.
I am able to start it via YaST > System > Runlevels.
There it says that network needs to started and starts both and says the changes are saved..
Then it seems to run till next boot.
Same thing with all my 12.1 systems, 32 and 64 bit, virtual and real HW.
But this is on 12.1 so I'm OT with this on this list.
On one of my 64-bit systems, systemd would intermittently hang on boot and never succeed (I waited 2 hours one time.). The failure rate was about 2 in 5 tries. I installed a new version with
zypper in -f http://download.opensuse.org/repositories/home:/fcrozat:/systemd/openSUSE_12...
(all on one line, of course), and it has not failed in 10+ tries.
Larry
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...
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.
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.
On 18/12/11 13:53, Christian Boltz wrote:
Hello,
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 ?
Yes, but OTOH the old initscripts are plain shell code and therefore grep-able and somehow self-documenting.
no, they are not.
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 :-)
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.
On Fri, Dec 16, 2011 at 4:37 PM, Cristian Rodríguez crrodriguez@opensuse.org 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
Larry Finger wrote:
On 12/17/2011 10:29 AM, Vahis wrote:
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?
Here at least postfix, no system mail.
I am able to start it via YaST > System > Runlevels.
There it says that network needs to started and starts both and says the changes are saved..
Then it seems to run till next boot.
Same thing with all my 12.1 systems, 32 and 64 bit, virtual and real HW.
But this is on 12.1 so I'm OT with this on this list.
On one of my 64-bit systems, systemd would intermittently hang on boot and never succeed (I waited 2 hours one time.). The failure rate was about 2 in 5 tries. I installed a new version with
zypper in -f http://download.opensuse.org/repositories/home:/fcrozat:/systemd/openSUSE_12...
I installed that version but I still need to start postfix in YaST.
It looks like network is now running when I do that though.
My networking has been fine all the time although it's been said not to work when starting postfix in YaST..
I'm seeing something about some scripts failing at the beginning of boot, but I can't find them afterwards.
/var/log/boot.msg does not show those.
Vahis
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.
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.
/var/log/boot.msg does not show those.
boot.msg has gone away, and is afaik, not coming back.
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:
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.
On 17/12/11 14:22, Greg Freemyer 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.
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
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.
On Sat, Dec 17, 2011 at 12:33 PM, Cristian Rodríguez crrodriguez@opensuse.org 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
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.
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 .
Cristian Rodríguez wrote:
On 17/12/11 14:33, Vahis wrote:
Where is it?
In the official update repo..
All I have postfix-2.8.5-3.5.1.x86_64
I don't see anything newer in updates.
all messages are logged to syslog , and can be found in /var/log/messages, later they will also be stored in journald binary log.
OK. There I see this many times: read from file /var/spool/postfix/pid/master.pid does not exist. Your service or init script might be broken.
Vahis
On Sat, Dec 17, 2011 at 12:45 PM, Cristian Rodríguez crrodriguez@opensuse.org 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
On 18/12/11 14:27, Vahis wrote:
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.
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 ?
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.
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,
You're wrong.
See https://bugzilla.novell.com/show_bug.cgi?id=732353 "Missing output from init-scripts"
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.
On Sat, Dec 17, 2011 at 1:11 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
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.
Excuse my terminology since I don't know systemd, but...
My understanding is a systemd unit file can simply provide a path to a /etc/init.d script and thus systemd compatibility is achieved without the use of a FULLY native systemd unit file.
As I read your plan, it assumes a goal of not using that approach for any of the services.
Again, I don't know enough to argue for or against a goal of FULLY native systemd unit files. That is why I'm saying a separate discussion of that goal should take place before arguing the merits of your plan.
Greg
* Carlos E. R. carlos.e.r@opensuse.org [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.
* Peter Nikolic p.nikolic1@btinternet.com [12-17-11 12:48]:
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.
Your case is rested :^).
But *you* are not contributing to solve *your* perceived problems. I just did a search on bugzilla and you have not reported a single instance nor are cc'ed on a single instance of a bug against systemd.
Your case is wilted.
But you continue to rave..... in broken/mis-spelled/lacking punctuated ?sentences?
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...
On Saturday 17 December 2011 18:36:20 Patrick Shanahan wrote:
- Peter Nikolic p.nikolic1@btinternet.com [12-17-11 12:48]:
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.
Your case is rested :^).
But *you* are not contributing to solve *your* perceived problems. I just did a search on bugzilla and you have not reported a single instance nor are cc'ed on a single instance of a bug against systemd.
Your case is wilted.
But you continue to rave..... in broken/mis-spelled/lacking punctuated ?sentences?
Right lets get something sorted once and for all time i am sick of your sarcastic replys item :::
I am NOT raving i could care less about someones over active sense of punctuation and as for spelling am i bothered NO the jist of the message is perfectly readable .
I have my opinions you have yours END OF !!! grow a pair .
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.
On 17/12/11 16:05, Bruce Ferrell wrote:
I agree, it's a nightmare.... systemd is. ignore it until it's ready for primetime.
It will never be if we ignore it, still not seeing evidence expressed in bug reports to address.
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)
On 17/12/11 16:26, upscope wrote:
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?
have you filled a bug report ? what is the date of the last change if you issue rpm -q --changelog systemd | less ?
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-12-17 19:26, Patrick Shanahan wrote:
- 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.
It is a forced migration already. 12.1 boots with that by default, it needs an extra effort not to, which you learn when it doesn't work.
Today I told at least 5 people on the forums to boot with systemv instead, and several others to report in bugzilla - which many will not do.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
-----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)
On Fri, Dec 16, 2011 at 4:37 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
Greg
-----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.
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
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
Per Jessen wrote:
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.
I use after.local to start my 6in4 tunnel on my firewall. How will something like that start?
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. ;-)
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".
Results now. ======== sepulot:/home/lancelot # service apache2 start redirecting to systemctl sepulot:/home/lancelot # ps fax|grep httpd 6675 pts/3 S+ 0:00 | _ grep --color=auto httpd 6667 ? Ss 0:00 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 6668 ? S 0:00 _ /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 6670 ? S 0:00 _ /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 6671 ? S 0:00 _ /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 6672 ? S 0:00 _ /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start 6673 ? S 0:00 _ /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D SYSTEMD -k start sepulot:/home/lancelot # /etc/init.d/vboxdrv setup Stopping VirtualBox kernel modules done Uninstalling old VirtualBox DKMS kernel modules done Trying to register the VirtualBox kernel modules using DKMS failed (Failed, trying without DKMS) Recompiling VirtualBox kernel modules done Starting VirtualBox kernel modules done sepulot:/home/lancelot # lsmod|grep vbox vboxpci 23288 0 vboxnetadp 13382 0 vboxnetflt 23882 0 vboxdrv 279868 3 vboxpci,vboxnetadp,vboxnetflt sepulot:/home/lancelot # service vboxdrv stop redirecting to systemctl sepulot:/home/lancelot # lsmod|grep vbox sepulot:/home/lancelot # service vboxdrv start redirecting to systemctl sepulot:/home/lancelot # lsmod|grep vbox vboxpci 23288 0 vboxnetadp 13382 0 vboxnetflt 23882 0 vboxdrv 279868 3 vboxpci,vboxnetadp,vboxnetflt
Regards Sid.
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
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.
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
On Saturday, December 17, 2011 04:30:01 PM Cristian Rodríguez wrote:
On 17/12/11 16:26, upscope wrote:
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?
have you filled a bug report ? what is the date of the last change if you issue rpm -q --changelog systemd | less ?
I did not file bug report since I got no useful information and problem doesn't occur everytime.
Here's the last couple. I can post while log if needed, I'm not sure when this started. Code -------------- rpm -q --changelog systemd | less
* Fri Nov 04 2011 fcrozat@suse.com - Fix rpm macros to only call presets on initial install (bnc#728104).
* Thu Oct 27 2011 fcrozat@suse.com - Add no-tmpfs-fsck.patch: don't try to fsck tmpfs mountpoint (bnc#726791).
* Wed Oct 19 2011 fcrozat@suse.com - Add avoid-random-seed-cycle.patch: fix dependency cycle between cryptsetup and random-seed-load (bnc#721666). - Add crash-isolating.patch: fix crash when isolating a service. - Fix bootsplash being killed too early. - Fix some manpages not being redirected properly. - Add storage-after-cryptsetup.service to restart lvm after cryptsetup. Fixes lvm on top of LUKS (bnc#724238).
* Fri Oct 14 2011 fcrozat@suse.com - Recommends dbus-1-python, do not requires python (bnc#716939) - Add private_tmp_crash.patch: prevent crash in debug mode (bnc#699829). - Add systemctl-completion-fix.patch: fix incorrect bash completion
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.
-----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:
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.
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.
openSUSE is not python (which is claimed to have exactly one way to do things) - but more like perl with TIMTOWTDI(=There Is More Than One Way To Do It) philosophy. We have 4 Desktop-Environments, countless windows-managers, email programs and web-browsers... So I wonder why having two init systems (that are even mostly compatible) for some years would be a problem. There will be extra packages with /etc/init.d/ scripts for a long time, so we can not just abandon the sysv-compat anyway - openSUSE is more than the core we ship and we need to consider this in our decisions.
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..
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) 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.
man 1 systemd-ask-password at least mentions a default timeout of 90s, but how can I be sure that this is the one applied here and how to adapt it?
googling for systemd cryptsetup timeout did only find bugreports, but nothing helpful. So as you know the extensive documentation better, you can certainly give a pointer to the page describing how to do this simple task.
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.
Where does the support effort come from (aside from fixing bugs that need fixing anyway)? I can see some effort in maintaining /etc/init.d/boot.* files together with their systemd equivalent. And some more effort if you start converting everything to service files (which IMHO is not needed so far)
so that as many use-cases as possible will be known to work with systemd.
your sugestion will actually delay those cases being known.
are we in a hurry?
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)
I run all my headless servers with Debian/stable, because they usually do sane decisions, have long maintenance and an abundance of packaged software. I'd love to have a green alternative. openSUSE+Evergreen is currently closest to being one.
Ciao Bernhard M.
On Sat, Dec 17, 2011 at 9:29 PM, Greg Freemyer greg.freemyer@gmail.com wrote:
On Fri, Dec 16, 2011 at 4:37 PM, Cristian Rodríguez crrodriguez@opensuse.org 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
On Sun, Dec 18, 2011 at 10:13 AM, Bernhard M. Wiedemann bernhardout@lsmod.de 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.
openSUSE is not python (which is claimed to have exactly one way to do things) - but more like perl with TIMTOWTDI(=There Is More Than One Way To Do It) philosophy. We have 4 Desktop-Environments, countless windows-managers, email programs and web-browsers... So I wonder why having two init systems (that are even mostly compatible) for some years would be a problem. There will be extra packages with /etc/init.d/ scripts for a long time, so we can not just abandon the sysv-compat anyway - openSUSE is more than the core we ship and we need to consider this in our decisions.
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.
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.
-Todd
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
Hi,
Am 18.12.2011 10:34, schrieb todd rme:
On Sun, Dec 18, 2011 at 10:13 AM, Bernhard M. Wiedemann 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.
Do we actually know (maybe I missed something in the long/different systemd threads) if the "current" maintainers of SysV won't do it anymore? At least I haven't seen such a statement (but as said I might have missed it so please point me there).
Wolfgang
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.
On 18/12/11 13:27, Sid Boyce wrote:
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.
Success! There is an apache2.service file in /lib/systemd/system [Unit] Description=apache After=syslog.target network.target Before=getty@tty1.service
[Service] Type=forking PIDFile=/var/run/httpd2.pid EnvironmentFile=/etc/sysconfig/apache2 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start ExecReload=/usr/sbin/start_apache2 -D SYSTEMD -t ExecReload=/bin/kill -HUP $MAINPID ExecStop=/usr/sbin/httpd2 -D SYSTEMD -k stop
[Install] WantedBy=multi-user.target
# ln -s /lib/systemd/system/apache2.service /etc/systemd/system/multi-user.target.wants/ Now apache2 starts automatically on boot. Regards Sid.
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
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
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
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?
During install I have always chosen to receive system mail for my own user. I did so also this time. So on top of that it needs to be started?
And it is supposed to run after the first initial start?
This is like great but how was I supposed to come up with this?
man systemctl ?
Will that answer to "What else am I missing compared to what I used to have running?"
Is this a bug or an intended behavior?
Vahis
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
Cristian Rodríguez wrote:
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...
OK.
I ran 'systemctl enable postfix.service' on another system where I hadn't installed the systemd that Larry Finger pointed out earlier.
The symlink was created but postfix didn't start.
I also have this in /var/log/messages, on both machines:
systemd[1]: PID 5251 read from file /var/spool/postfix/pid/master.pid does not exist. Your service or init script might be broken.
I'll install the newer systemd...
Vahis
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.
On 18/12/11 15:43, 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?
really ? for using a new laptop with a fresh install which BIOS thought I am on Windows (just fixed it :-D) you are questioning my competence ?
wow.
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:
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.
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.
In the future the systemd Journal feature will offer access to this kind of information.
Thanks
Lars
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
Vahis wrote:
Cristian Rodríguez wrote:
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...
OK.
I ran 'systemctl enable postfix.service' on another system where I hadn't installed the systemd that Larry Finger pointed out earlier.
The symlink was created but postfix didn't start.
I also have this in /var/log/messages, on both machines:
systemd[1]: PID 5251 read from file /var/spool/postfix/pid/master.pid does not exist. Your service or init script might be broken.
I'll install the newer systemd...
zypper in -f http://download.opensuse.org/repositories/home:/fcrozat:/systemd/openSUSE_12...
Now postfix starts at boot.
Vahis
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
On Sun, Dec 18, 2011 at 08:16:06PM +0100, Rüdiger Meier wrote: [ 8< ]
I don't complain about the order. I can't login via serial console when using systemd.
If that's the case please ensure to file a bug report.
Thanks
Lars
On 18/12/11 17:27, Vahis wrote:
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 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.
Cristian Rodríguez crrodriguez@opensuse.org writes:
On 17/12/11 07:38, Sid Boyce wrote:
It's frustrating to find after switching to systemd,
Which services do not start?
The automounter doesn't work with NFS shares, rpc.idmapd isn't started either (probably a follow-up bug). See my report: https://bugzilla.novell.com/show_bug.cgi?id=737547
Sebastian
Cristian Rodríguez crrodriguez@opensuse.org 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
On 18/12/11 21:22, Sebastian Freundt wrote:
Cristian Rodríguezcrrodriguez@opensuse.org 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
I am looking at the NFS bits, the aux consoles part has to be looked by someone else
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.
On Saturday 17 of December 2011 15:33EN, Thomas Leineweber wrote:
I am in favor of the proposal. It is a nightmare to support two different init systems.
It may be but this doesn't mean sysvinit is the one to be discarded...
Michal Kubeček
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
Le samedi 17 décembre 2011 à 18:59 +0100, Per Jessen a écrit :
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,
You're wrong.
See https://bugzilla.novell.com/show_bug.cgi?id=732353 "Missing output from init-scripts"
And upstream is also thinking to always enable log for sysv initscripts (currently relying on quiet or systemd.sysv_console value).
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.
Am 18.12.2011 14:27, schrieb Sid Boyce:
I enabled apache2.service in /lib/systemd/system.preset/default-openSUSE.preset but that didn't fix it on a reboot.
I think that's just a template, not the "live" setting.
On my updated system (from 11.4 to 12.1) some services were not enabled during update. For example postfix, which I just enabled right now with "systemctl enable postfix.service" and thus did not start during boot.
So if you have services not starting during boot, check if they are enabled:
server:~ # chkconfig postfix Note: Forwarding request to 'systemctl is-enabled postfix.service'. disabled postfix off
No wonder it did not start :-)
That it was disabled during the update is probably a bug, but bugs are here to be fixed, so let's fix it :-)
Best regards,
Stefan
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.
Am 17.12.2011 21:51, schrieb James Knott:
Per Jessen wrote:
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.
I use after.local to start my 6in4 tunnel on my firewall. How will something like that start?
You use a proper init script with the really needed dependencies? What does 6in4 need? Networking I suppose? So create an init script that does exactly that.
I had a similar thing with wwwoffle (which always starts up in offline mode), which I had solved in after.local before:
server:~ # cat /etc/init.d/wwwoffle-online #!/bin/sh ### BEGIN INIT INFO # Provides: wwwoffle-compat # Required-Start: wwwoffle # Should-Start: # Required-Stop: # Should-Stop: # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: set wwwoffle online ### END INIT INFO . /etc/rc.status rc_reset case "$1" in start) echo -n "setting wwwoffle online" ...
Works beautifully: server:~ # systemctl status wwwoffle-online.service wwwoffle-online.service - LSB: set wwwoffle online Loaded: loaded (/etc/init.d/wwwoffle-online) Active: active (exited) since Sun, 18 Dec 2011 21:18:37 +0100; 14h ago CGroup: name=systemd:/system/wwwoffle-online.service
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.
Le lundi 19 décembre 2011 à 11:26 +0100, Stefan Seyfried a écrit :
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.
and it should work. But there are still issues in our chkconfig. Help welcome, for anybody with perl skill to patch our chkconfig.
However, there are obviously some bugs in the update process from sysv to systemd which lead to services being disabled which were not before.
postfix was shipping systemd .service file and was not rebuild when we fixed an issue in the systemd rpm macros regarding migration.
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
Le lundi 19 décembre 2011 à 11:41 +0100, Ludwig Nussel a écrit :
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.
No shell involded at all (and this also included all the work which is done for each initscript just to start one executable), no startproc (since systemd is doing the heavy lifting for us) and much more readable than an initscript :) Another important point is to be able to upstream .service and no longer maintain them but share them across distributions.
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.
On 19.12.2011 11:37, Michael Schroeder wrote:
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.
You can only say that if you stayed out of distribution development. A lot of effort was put into keeping the sysv system working. The command parsing /etc/inittab might be small, but all the scripts and commands called from there are obviously a lot to maintain - and are 99.8% SUSE only and not shared with other distributions.
Greetings, Stephan
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 ;-)
On 12/16/2011 9:11 AM, 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 ?
Why is the burden on the user? They are already suffering a sucky product. This isn't really the "help thy self" issue so many people keep trying to make it out to be.
The crap was pushed out as a release and so everyone, normal users who think they are "helping thy selves" simply by only using official released software instead of betas and Factory, were made to suffer it without being asked.
It's definitely the burden of the people who decided for the rest of us to make it better.
Oh, they aren't paying for the product? So, that makes it ok for the product to suck? OK well, then what? If the product is allowed to suck, or even merely gain the reputation for sucking, deserved or not in your own eyes, what then?
It's not in your own interests to keep rebuffing user complaints.
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.
When I don't see that acknowledgement of responsibility for causing the users grief, I am hardly surprised when users are unsympathetic and unwilling to go to the trouble of good bug reports. A _good_ bug report is actually a fair amount of work.
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.
On 12/19/2011 3:20 PM, Christian Boltz wrote:
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.
I'm going to have a similar problem with LXC VM's. There is no "service" and yet there is definitely a start and a stop and two necessary forms of status, and that status needs to list the status of individual vm's as well as provide a summary exit value that can inform init (be that sysv or upstart or systemd etc...) when it's ok to finish powering down the host, or not. Saying that lxc is merel "running" or "not running" really makes no sense, but it is useful for the purpose of safe and graceful shutdown of the host to treat "running" as "are any vm's currently running?" If even one is, then do not shut down the host yet, ask that vm to shutdown and wait for it to do so. Do the same for all configured vm's (having recognized config files in a single recognized spot) and don't worry about the possibility of manually created & started vm's, just like you don't worry about the possibility of manually executed instances of vsftpd.
I expect it will be perfectly possible to create a meaningful unit file that takes the place of my rclxc but I am unnerved by reading comments about too-simple assumptions systemd makes. No such thing as any other verbs besides start/stop/status? Gee, what a nice simple world they live in. I do not live in that world. I am hoping it's not really as bad as that.
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
On Mon, Dec 19, 2011, at 04:09 PM, Brian K. White wrote:
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.
Why would you have to do that? systemd supports the old init.d scripts as a stated feature. I know if it didn't on my system several things that do work perfectly with systemd would not. The dyndns client ddclient is an example off the top of my head.
Tim
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
Patrick Shanahan wrote:
- Peter Nikolic p.nikolic1@btinternet.com [12-17-11 12:48]:
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.
Your case is rested :^).
But *you* are not contributing to solve *your* perceived problems. I just did a search on bugzilla and you have not reported a single instance nor are cc'ed on a single instance of a bug against systemd.
---- Having filed a bunch of bugs only to find most of them unfixed years later, is not exactly encouraging of filing bugs...
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.
On Tuesday 20 of December 2011 00:48EN, Cristian Rodríguez wrote:
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.
This would mean forcing systemd on users whether they want it or not, whether it gives them something or not, even whether it works for them or not. Please don't do it. Please show first that systemd can work reliably and that it can give the users (admins) something that the old solution didn't. This is the way to persuade people that the new solution is better than the old one, not forcing it on them and not giving them a choice.
My proposition is: don't even start to talk about taking normal init away until there is at least one distribution release where systemd works at least as well as init does (and 12.1 definitely isn't one).
Michal Kubeček
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
Le lundi 19 décembre 2011 à 23:53 +0100, Lars Müller a écrit :
Unfortunately systemd testing while the development of openSUSE 12.1 didn't got the same attention as it got with or after the release.
People either didn't test it, or didn't report bug : let's just see how many bugs we are getting RIGHT NOW because we are talking about dropping sysvinit and people didn't spend time to report their issues.
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
Yes, it is.
I've been working on it for almost a month, to try to get good feedback and to not do 10 maintenance update in a row, with one bug fix after another.
It is in maintenance team hand for a week now, so we'll see when it is been released.
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
On 20/12/11 07:15, Michal Kubeček wrote:
On Tuesday 20 of December 2011 00:48EN, Cristian Rodríguez wrote:
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.
This would mean forcing systemd on users whether they want it or not, whether it gives them something or not, even whether it works for them or not. Please don't do it. Please show first that systemd can work reliably and that it can give the users (admins) something that the old solution didn't. This is the way to persuade people that the new solution is better than the old one, not forcing it on them and not giving them a choice.
My proposition is: don't even start to talk about taking normal init away until there is at least one distribution release where systemd works at least as well as init does (and 12.1 definitely isn't one).
Michal Kubeèek
I couldn't agree more. Many shops where QC must be convinced, would consider systemd a disruptive change which would certainly not be passed as fit for deployment currently and so would consign it to test only.
If that meant not deploying 12.2, fine, they'd have another look at systemd status at 12.3.
I have been in such meetings with corporate customers who would readily turn down the strongest of technical recommendations if they thought there was the slightest chance of an exposure as they see it, even one that could and should be readily circumvented or fixed.
A Saturday job that should have easily been completed in 8 hours actually took 12 hours on Saturday and 9 hours on Sunday because of the customer's "unjustified" fears - his prerogative certainly and that was without a single hitch.
Right or wrong, the customer will be the judge of what's in their best interest. Regards Sid.
On Fri, Dec 16, 2011 at 11:10 AM, Cristian Rodríguez crrodriguez@opensuse.org 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.
On Sat, Dec 17, 2011 at 2:33 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
If an init script does its job... why not use it?
I've heard something that is indeed useful in this or any context: programmers' biggest strength is that they're lazy bastards.
This means, we'll always take the path of least effort, and in doing so, do more in less time, and in a way that is easier to maintain in the future. This includes not rewriting scripts that do a good job already.
On Tue, Dec 20, 2011 at 7:29 AM, Claudio Freire klaussfreire@gmail.com wrote:
On Fri, Dec 16, 2011 at 11:10 AM, Cristian Rodríguez crrodriguez@opensuse.org 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
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.
Dom
Greg Freemyer wrote:
On Tue, Dec 20, 2011 at 7:29 AM, Claudio Freireklaussfreire@gmail.com wrote:
On Fri, Dec 16, 2011 at 11:10 AM, Cristian Rodríguez crrodriguez@opensuse.org 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
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.
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?
Regards,
Christian Boltz
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: <path_for_pid_file> (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).
On Sun, Dec 18, 2011 at 4:02 PM, Lars Müller lmuelle@suse.de wrote:
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.
In the future the systemd Journal feature will offer access to this kind of information.
Syslog should be able to handle this right now just as well.
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
On Mon, Dec 19, 2011 at 5:52 PM, Brian K. White brian@aljex.com wrote:
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.
When I don't see that acknowledgement of responsibility for causing the users grief, I am hardly surprised when users are unsympathetic and unwilling to go to the trouble of good bug reports. A _good_ bug report is actually a fair amount of work.
+1
You know, flies and honey go together.
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
On Tuesday 20 December 2011 17:09:22 Claudio Freire wrote:
On Mon, Dec 19, 2011 at 5:52 PM, Brian K. White brian@aljex.com wrote:
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.
When I don't see that acknowledgement of responsibility for causing the users grief, I am hardly surprised when users are unsympathetic and unwilling to go to the trouble of good bug reports. A _good_ bug report is actually a fair amount of work.
+1
You know, flies and honey go together.
+1
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
On 12/20/2011 2:21 PM, Christian Boltz wrote:
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.
Indeed. I don't know how else I could make LXC VM's start up and shut down with the host gracefully. There is no pid file, there is no process, there is however a combination of commands to run that tell you it is OK or it is NOT OK to proceed with host shutdown.
I *could* write a watchdog that essentially loops these commands the entire time from when a .service is started. KLUDGE! A backwards march of progress.
Instead of querying the system once when you want to know something, you're querying it continuously forever just so that systemd can find out via it's too-limited api? No.
The static one-shot kind of .service file like iptables: http://en.gentoo-wiki.com/wiki/Systemd#iptables Doesn't seem to apply. as someone else discovered, they do nothing when you try to run them again later.
I could make ExecStart and ExecStop scripts easy enough. They could include all necessary logic to avoid doing anything that has already been done, and do all necessary things without making any unsafe assumptions about other things that appear to have been done.
At shutdown time, as long as the overall host shutdown blocks until ExecStop returns _with an agreeable error level_, then I'll be ok.
So far so good.
Status? Yeah if only for sysadmin consistency, ExecStatus is really needed. There is no way an ExecStart could create a fake pid file that actually means anything unless it was written and updated by a watchdog just for that. And we do want the sys admin to be able to query the current running/not-running status of a service without having to remember or look up random inconsistent service-specific commands.
Another idea, it might be possible to install incron (inotify, not cron) jobs to monitor something from inside of each container vm. That could theoretically update a fake pid file any time any vm's status changed, without requiring a 24/7 watchdog other than the kernel itself via inotify and incrond. incrond runs 24/7 but it's generically useful like cron so that's a tolerable process. But the incron jobs themsevles only fire off when the conditions the incrontab entry specifies occur (file creation, name change, etc). It would be a bit delicate and I don't like that since the proper startup/shutdown of whole entire vm servers is even more critical than any normal single service.
You might be able to do some kind of incron based trick like that for your service too. Until ExecStatus exists, at least it would avoid having to write a kludgy forever looping watchdog script.
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 wrote:
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.
If that's an issue, there's a real problem. sysvinit is about more than starting services. And from Lennart's blog posts, I always assumed that systemd shall fold in all of that aspects -- I even suspect that they want to fold in cron at some future point.
But more an issue for this thread: If systemd currently only replaces the "starting services" aspect of sysvinit, what new system does the rest? As long as this isn't cleared up, sysvinit should not be abandoned, IMNSHO.
Joachim
On Wed, Dec 21, 2011 at 5:31 AM, Frederic Crozat fcrozat@suse.com 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.
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
Ciao Bernhard M.
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
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 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.
osc bugowner?
There's no guarantee the account in obs is also valid in bugzilla nor that the person listed there still cares though. Also, many devel projects have tons of maintainers but no bug owner.
cu Ludwig
On 20/12/11 09:51, Claudio Freire wrote:
On Sat, Dec 17, 2011 at 2:33 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
On 21/12/11 17:41, Claudio Freire wrote
Not to mention dumb.
It is not dumb, it is called sanity. is:
-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 ;-)
On Sun, Dec 25, 2011 at 2:16 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
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.
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 _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.
On Sun, Dec 25, 2011 at 7:50 PM, Graham Anderson graham.anderson@gmail.com 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.
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...
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
On Mon, Dec 26, 2011 at 2:47 AM, Peter Linnell mrdocs@opensuse.org wrote:
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 agree.
But simple things should be simple, while complex things possible. ATM, systemd is simple things are simple, mildly complex things possible, complex things not possible.
Well, unless I'm mistaken about its capabilities.
Really, missing an ExecStatus command is a big thing. ExecKill comes next.
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..
On Mon, Dec 26, 2011 at 11:53 AM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
Really, missing an ExecStatus command is a big thing. ExecKill comes next.
What for ? ExecStart does account the exit status, ExecKill makes no sense..
Forget AppArmor, you seem not to like the example. Take the VM example, where shutting down or querying the status of the VMs is nothing like checking a PID.
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? That's what ExecKill would be for.
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
On Mon, Dec 26, 2011 at 1:04 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
On 26/12/11 13:33, Claudio Freire wrote:
On Mon, Dec 26, 2011 at 1:04 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
On Mon, Dec 26, 2011 at 2:04 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
Similar, but not the same.
On 26/12/11 14:09, Claudio Freire wrote:
On Mon, Dec 26, 2011 at 2:04 PM, Cristian Rodríguez crrodriguez@opensuse.org 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.
On Mon, Dec 26, 2011 at 2:34 PM, Cristian Rodríguez crrodriguez@opensuse.org wrote:
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.
So, you say ExecStop should do the kill part too?
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
On 12/26/2011 12: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.
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.
Wrong.
-----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 SIGNED MESSAGE----- Hash: SHA256
On 2011-12-18 17:53, Christian Boltz wrote:
Additionally there's the usual (non)argument that everybody knows initscripts quite well, so nobody needs documentation.
And in fact the traditional boot process is well documented in the openSUSE PDF book. SystemD is not.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" (Minas Tirith))
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.
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. P.P.S. Apologies if this is a duplicate - first post.
On 04/01/12 01:10, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2011-12-18 17:53, Christian Boltz wrote:
Additionally there's the usual (non)argument that everybody knows initscripts quite well, so nobody needs documentation.
And in fact the traditional boot process is well documented in the openSUSE PDF book. SystemD is not.
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/
iF4EAREIAAYFAk8DpwEACgkQja8UbcUWM1xWRAD/f4k3DJTkZRhtOPGvVmKR73Y4 I+u+fywfPF76FJSLFukA/ioGyFO7uxpeZFt63brRZfy3u5qKRXqYtzGqgCmPy6vZ =KPGI -----END PGP SIGNATURE-----
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
On Sun, 05 Feb 2012 06:46:52 +0000 Michael Davies llemikebyw@aol.com wrote:
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?
There are some wiki pages starting with: http://en.opensuse.org/systemd
You can find the rest in a horizontal menu right below. Please review and give your opinion, possibly in a new thread dedicated to systemd documentation.
Another documentation source is http://doc.opensuse.org/ with current 12.1 listed as a first section that probably needs review regarding systemd implementation in openSUSE.
Below are listed all those documents: http://doc.opensuse.org/documentation/html/openSUSE/opensuse-startup/ http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/ http://doc.opensuse.org/documentation/html/openSUSE/opensuse-security/ http://doc.opensuse.org/documentation/html/openSUSE/opensuse-kvm/ http://doc.opensuse.org/documentation/html/openSUSE/opensuse-tuning/
On 05/02/12 03:46, Michael Davies wrote:
- 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-02-05 22:41, Cristian Rodríguez wrote:
Does any of those books describe the suse boot process ? hint, it is not the same of fedora, ubuntu,debian etc,,
Yes. In detail.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
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
On 05/02/12 20:20, Ruediger Meier wrote:
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.
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
The lack of "books" is also not a technical argument, neither is what languages someone use to develop a program or not.
Oh and BTW.. some systemd components are written in Vala, (C#-like language which is then translated and compiled into C)
On Monday 06 February 2012, Cristian Rodríguez wrote:
On 05/02/12 20:20, Ruediger Meier wrote:
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.
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
The lack of "books" is also not a technical argument, neither is what languages someone use to develop a program or not.
You are missing the point again. The language statement "shell/regexp is evil" comes from Poettering himself not from me. And I don't like that statement - even if "don't like" may not be "technical criticism". There is no need to do technical criticism on such idiotic statements.
With open/transparent I mean that a user (non-developer) is able to debug/trace his system. In other words that the user is able to _use_ it's system.
Oh and BTW.. some systemd components are written in Vala, (C#-like language which is then translated and compiled into C)
sweet_f_a@gmx.de wrote:
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...
Lennart isn't writing this alone. SUSE employed Kay Sievert is the other person developing systemd. Also got a convenient Argument against Kay?
Philipp
Am 06.02.2012 02:52, schrieb Philipp Thomas:
sweet_f_a@gmx.de wrote:
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...
Lennart isn't writing this alone. SUSE employed Kay Sievert is the other person developing systemd. Also got a convenient Argument against Kay?
AFAIK Kay Sievers is RedHat employed nowadays fwiw.
Sorry for the noise, Wolfgang
On Sunday 05 of February 2012 18:41EN, Cristian Rodríguez wrote:
what of the many different "init process" is documented, fedora,debian, opensuse ..etc all use different init systems.
As far as I can tell, there is no substantial difference between init in (Open)SuSE, Fedora or Debian. What is different, is the structure of init scripts, not init itself. And even those aren't as different as they used to be in the past, at least among LSB compliant distributions.
And IMHO this makes a big difference because reading (and writing) shell scripts is something every linux admin must know.
On the other hand, I don't like the "every book describes" argument either. Even today, most books about Linux teach people to use ifconfig to configure their network interfaces - tool which is obsolete since kernel 2.2.
Michal Kubeček
Le 06/02/2012 00:20, Ruediger Meier a écrit :
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?
listen, I'm completely out of this systemd stuff, but It's obvious for me that it's not *one* people that makes systemd so widely accepted as the next boot system.
I don't think so many people follow *blindly* the original author.
And, that said, if anybody can show a much better news system, I'm sure it will be supported.
Change is always a pain, because it needs changing his own habits, but change is life, isn't it?
jdd
On Monday 06 of February 2012 10:15EN, jdd wrote:
Le 06/02/2012 00:20, Ruediger Meier a écrit : And, that said, if anybody can show a much better news system, I'm sure it will be supported.
Change is always a pain, because it needs changing his own habits, but change is life, isn't it?
You are silently assuming there _has_ to be a change because every change is automatically an improvement. Neither is true.
Michal Kubeček
Hi,
On Sun, Feb 05, Cristian Rodríguez wrote:
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.
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
I can contribute some technical criticism: systemd is unreliable!
After updating two of my machines to 12.1, I noticed that the systems sometimes come up with the network down (only loopback interface is up). Entering "rcnetwork restart" as root only yields the output "redirecting to systemd", but the network still is down. Since my children do not have the root password on their machine, they simply would power cycle the machine so often until the network finally works.
Some colleagues attributed my problems to the fact that I'm using static addresses and not dhcp. But nobody has an idea what the real problem is, nobody can give me a hint how to debug it.
I consider a system that comes up correctly only with a probability of around 70% as utterly broken.
Of course I filed a bug report weeks ago, but nobody seems to have an idea.
Finally I dropped systemd and replaced it by sysvinit-init and all my problems are gone.
Hubert Mantel
Am Montag, 6. Februar 2012, 11:00:19 schrieb Michal Kubeček:
On Monday 06 of February 2012 10:15EN, jdd wrote:
Le 06/02/2012 00:20, Ruediger Meier a écrit : And, that said, if anybody can show a much better news system, I'm sure it will be supported.
Change is always a pain, because it needs changing his own habits, but change is life, isn't it?
You are silently assuming there _has_ to be a change because every change is automatically an improvement. Neither is true.
What's the point of arguing any longer? Any systemxy package that has an active maintainer can be part of openSUSE. You can neither force people to maintain a package nor to not do so. You can contribute yourself or pay somebody to maintain it – or you can just wait and see if you are lucky and somebody else does the job.
What Ruediger wrote is true the other way around as well: a much better old system, I'm sure will be supported.
If nobody wants to maintain it the conclusion is obvious if one takes Ruediger's line of argument. If somebody will maintain it there is no issue for those who claim it to be better (suited for them).
I would not say it's about better/worse but simply about maintained/unmaintained and arguing does not change anything about that. Money or contribution do – nothing else.
Sven
On Monday, February 06, 2012 11:15:43 Hubert Mantel wrote:
Hi,
On Sun, Feb 05, Cristian Rodríguez wrote:
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.
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
I can contribute some technical criticism: systemd is unreliable!
After updating two of my machines to 12.1, I noticed that the systems sometimes come up with the network down (only loopback interface is up). Entering "rcnetwork restart" as root only yields the output "redirecting to systemd", but the network still is down. Since my children do not have the root password on their machine, they simply would power cycle the machine so often until the network finally works.
Some colleagues attributed my problems to the fact that I'm using static addresses and not dhcp. But nobody has an idea what the real problem is, nobody can give me a hint how to debug it.
I consider a system that comes up correctly only with a probability of around 70% as utterly broken.
Of course I filed a bug report weeks ago, but nobody seems to have an idea.
What's the bugzilla number?
Finally I dropped systemd and replaced it by sysvinit-init and all my problems are gone.
Glad that you found the culprit - so let's fix it. ;)
Andreas
Hubert Mantel mantel@suse.de wrote:
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
I can contribute some technical criticism: systemd is unreliable!
So why not using SMF instead?
Jörg
On Monday 06 of February 2012 11:20EN, Sven Burmeister wrote:
What's the point of arguing any longer? Any systemxy package that has an active maintainer can be part of openSUSE. You can neither force people to maintain a package nor to not do so. You can contribute yourself or pay somebody to maintain it – or you can just wait and see if you are lucky and somebody else does the job.
What Ruediger wrote is true the other way around as well: a much better old system, I'm sure will be supported.
What I can see - and what I don't like at all - is a group of people who are planning to remove System V init from distribution even if it is maintained and even if it works much better than systemd. Moreover, they keep repeating that System V init will go eventually - probably because they believe that if they repeat it enough times, people will accept it as a given fact.
Michal Kubeček
Hi,
On Mon, Feb 06, Joerg Schilling wrote:
I can contribute some technical criticism: systemd is unreliable!
So why not using SMF instead?
What are you referring to?
Jörg
Hubert Mantel
Am Montag, 6. Februar 2012, 11:56:18 schrieb Michal Kubeček:
What I can see - and what I don't like at all - is a group of people who are planning to remove System V init from distribution even if it is maintained and even if it works much better than systemd. Moreover, they keep repeating that System V init will go eventually - probably because they believe that if they repeat it enough times, people will accept it as a given fact.
And who would keep the maintainer from submitting it? Are you suggesting that openSUSE wants to oppress contributions?
Sven
Andreas Jaeger aj@suse.com writes:
On Monday, February 06, 2012 11:15:43 Hubert Mantel wrote:
Hi,
On Sun, Feb 05, Cristian Rodríguez wrote:
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.
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
I can contribute some technical criticism: systemd is unreliable!
After updating two of my machines to 12.1, I noticed that the systems sometimes come up with the network down (only loopback interface is up). Entering "rcnetwork restart" as root only yields the output "redirecting to systemd", but the network still is down. Since my children do not have the root password on their machine, they simply would power cycle the machine so often until the network finally works.
Some colleagues attributed my problems to the fact that I'm using static addresses and not dhcp. But nobody has an idea what the real problem is, nobody can give me a hint how to debug it.
I consider a system that comes up correctly only with a probability of around 70% as utterly broken.
Of course I filed a bug report weeks ago, but nobody seems to have an idea.
What's the bugzilla number?
737636
Sebastian
On Monday 06 February 2012, Sven Burmeister wrote:
Am Montag, 6. Februar 2012, 11:56:18 schrieb Michal Kubeček:
What I can see - and what I don't like at all - is a group of people who are planning to remove System V init from distribution even if it is maintained and even if it works much better than systemd. Moreover, they keep repeating that System V init will go eventually - probably because they believe that if they repeat it enough times, people will accept it as a given fact.
And who would keep the maintainer from submitting it? Are you suggesting that openSUSE wants to oppress contributions?
Sven
Hehe maybe this got forgotten. But about 600 posts above there was the OP's original email
Subject: Phasing out sysvinit [...] Phase 1:
- Delete sysvinit scripts [...]>
So it's not only about having a maintainer. Or should sysvinit maintainer re-submit it always if another one removes it?
Nobody would complain about systemd if it's maintainers would keep their fingers away from sysvinit.
cu, Rudi
Le lundi 06 février 2012 à 11:29 +0000, Sebastian Freundt a écrit :
Andreas Jaeger aj@suse.com writes:
On Monday, February 06, 2012 11:15:43 Hubert Mantel wrote:
Hi,
On Sun, Feb 05, Cristian Rodríguez wrote:
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.
Sorry that's utter bullshit dogma. "I don't like it" it is not technical criticism, and personal attacks against one developer discredits your point completely.
I can contribute some technical criticism: systemd is unreliable!
After updating two of my machines to 12.1, I noticed that the systems sometimes come up with the network down (only loopback interface is up). Entering "rcnetwork restart" as root only yields the output "redirecting to systemd", but the network still is down. Since my children do not have the root password on their machine, they simply would power cycle the machine so often until the network finally works.
Some colleagues attributed my problems to the fact that I'm using static addresses and not dhcp. But nobody has an idea what the real problem is, nobody can give me a hint how to debug it.
I consider a system that comes up correctly only with a probability of around 70% as utterly broken.
Of course I filed a bug report weeks ago, but nobody seems to have an idea.
What's the bugzilla number?
737636
Which is waiting for your feedback..
Am Montag, 6. Februar 2012, 12:33:46 schrieb Ruediger Meier:
Hehe maybe this got forgotten. But about 600 posts above there was the OP's original email
Subject: Phasing out sysvinit [...] Phase 1:
- Delete sysvinit scripts [...]>
So it's not only about having a maintainer. Or should sysvinit maintainer re-submit it always if another one removes it?
Nobody would complain about systemd if it's maintainers would keep their fingers away from sysvinit.
I think you misunderstood. AFAIU Cristian wants to remove those scripts in case systemd is used. He does not care about what you do if you operate sysvinit.
And since you and those complaining about systemd would not use systemd anyway, why do you care whether there are sysvinit scripts removed for a systemd environment?
If you come up with a maintainer include the sysvinit scripts in the sysvinit package.
Sven
This has become an unproductive brawl . . . maybe it would be useful to just step back and take a deep breath? IMO the high temperature is muddying the water. And a lot of the discussion is down in the weeds.
If systemd (or a close counterpart with essentially the same architecture) is in the process of being adopted as the new defacto boot system for the main Linux distributions such as Fedora, Mandriva, Ubuntu, etc. then it isn't a matter of if, it's a matter of when and how. Presumably even Debian, on purpose a later adopter, will eventually adopt systemd. So openSUSE will ultimately need to adopt systemd, or fall behind in a critical sub-system.
If systemd is not emerging as a new defacto standard and the main distros are going to splinter into entirely different boot sub-systems, then the pros and cons of not only systemd but the implications of such a split, is what should be debated. But the debate should be based upon the merits of the new sub- system, the implications of going a different direction or staying with the old, etc. (And there may be implications beyond the obvious.) While the transition is absolutely critical, how that gets managed is a different discussion than whether there should be a transition at all.
Presuming that systemd will ultimately be adopted, the next reality to accept is the limitation of the affected and available developement resources. If "the lab" (whomever that is for openSUSE) says that it cannot effectively support 2 boot sub-systems, then again it becomes a question of how to most effectively manage the transition to the new. Administrators can and should contribute to this process. The lab should take very seriously that making the transition as painless as possible is every bit as important as doing the new sub-system implementation itself.
Most of the objections posted have been "when" and "how" objections, and those are very valid concerns. Judging from the problems with systemd in 12.1 upgrades, it does appear that the first phase rollout was not well managed. The lab cannot expect administrators let alone users to know what they don't know, and responding to concerns and frustrations with "read the man page" only adds fuel to the fire. Similarly, the lab owes the community a well- developed and complete transition plan that proactively addresses concerns. There needs to be ample time for adminstrators to prepare, documentation needs to have been completed, comprehensive transition testing needs to be done. And it needs to be understood that given the importance of a well-managed transition, either more elapsed time may be required and/or other tasks may have to slip.
In short, my recommendation is that this issue be approached from a management perspective. The first question to decide is a binary one, systemd or no systemd - and without blurring that with issues of how to go about it or water that's under the bridge. If the answer is yes, then the focus should turn to the most effective way of getting there. If the answer is no, then the community lives with the implications of that decision.
On Monday 06 of February 2012 12:51EN, Sven Burmeister wrote:
And since you and those complaining about systemd would not use systemd anyway, why do you care whether there are sysvinit scripts removed for a systemd environment?
If you come up with a maintainer include the sysvinit scripts in the sysvinit package.
They wouldn't be removed from "a systemd environment" as they are not in one. These scripts (most of them) are part of the packages relevant services are implemented by. Which is kind of necessary because if you want them in sysvinit package, you can have only a certain fixed set of scripts in it, not all scripts for all services you could possibly have in the system. It is similar to the dilemma whether AppArmor profiles should be in apparmor-profiles or in the relevant packages with the programs; the difference being that a daemon is fully usable without its AppArmor profile.
So what are you really planning to do is (1) order all service package maintainers to include a systemd unit file and (2) forbid them to include a LSB compliant init script.
Michal Kubeček
Le 06/02/2012 11:00, Michal Kubeček a écrit :
You are silently assuming there _has_ to be a change because every change is automatically an improvement. Neither is true.
no. I notice *there is* a change and acknowledge it, and try to make the problems fixed
jdd
On Monday 06 of February 2012 07:12EN, Dennis Gallien wrote:
If systemd (or a close counterpart with essentially the same architecture) is in the process of being adopted as the new defacto boot system for the main Linux distributions such as Fedora, Mandriva, Ubuntu, etc. then it isn't a matter of if, it's a matter of when and how. Presumably even Debian, on purpose a later adopter, will eventually adopt systemd. So openSUSE will ultimately need to adopt systemd, or fall behind in a critical sub-system.
I think this is the basic problem. You take as obvious fact that traditional System V init simply has to go and the only questions are when, how and whether by systemd or something similar. I'm sorry but this isn't obvious to me at all.
Don't take me wrong, I'm not saying System V init with the infrastructure of init scripts is the best possible solution and can't bereplaced _ever_. But such replacement should come from real need of improvement and address real problems. Systemd is pushed by wishes of people behind it and by creating of lists of artificial reasons invented by these people (systemd is better because it does what systemd came with and what noone needed before).
There never was an actual discussion _whether_ the transition should take place. People behind systemd keep pretending that it is so obvious that there is no need for such discussion. I don't agree. Before we talk about "when" and "how", the "if at all" discussion definitely should take place.
Michal Kubeček
On Monday 06 of February 2012 13:35EN, jdd wrote:
Le 06/02/2012 11:00, Michal Kubeček a écrit :
You are silently assuming there _has_ to be a change because every change is automatically an improvement. Neither is true.
no. I notice *there is* a change and acknowledge it, and try to make the problems fixed
Looks like we are talking about two different changes. There _is_ systemd as an alternative to System V init and init scripts. This is the change there _is_. What I'm talking about is throwing System V init away. This is still a plan of a certain group of people and it's too early to take it as "just a matter of time".
Michal Kubeček
Am Montag, 6. Februar 2012, 13:23:05 schrieb Michal Kubeček:
So what are you really planning to do is (1) order all service package maintainers to include a systemd unit file
There might be indeed a rule "include a script/file for the default init system". Maintainers were "ordered" to include a script when sysvinit was default, now the same would apply to systemd. I do not see a change in rules there. Only a change in defaults.
and (2) forbid them to include a LSB compliant init script.
Alleged oppression once again… If the default changes other things have to change as well. True. Would be exactly the same if the change was from systemd to sysvinit.
I'm sure there is a packaging way to check whether systemd or syvinit is installed and install the legacy scripts accordingly when installing a service – assuming that service maintainers bother to maintain scripts for the non- default sysvinit.
Sven
Le 06/02/2012 13:44, Michal Kubeček a écrit :
Looks like we are talking about two different changes. There _is_ systemd as an alternative to System V init and init scripts. This is the change there _is_. What I'm talking about is throwing System V init away. This is still a plan of a certain group of people and it's too early to take it as "just a matter of time".
it seems obvious that few people want to maintain systemV inits, if not there would be no problem at all
jdd
On Monday, February 06, 2012 07:39 AM Michal Kubeček wrote:
On Monday 06 of February 2012 07:12EN, Dennis Gallien wrote:
If systemd (or a close counterpart with essentially the same architecture) is in the process of being adopted as the new defacto boot system for the main Linux distributions such as Fedora, Mandriva, Ubuntu, etc. then it isn't a matter of if, it's a matter of when and how. Presumably even Debian, on purpose a later adopter, will eventually adopt systemd. So openSUSE will ultimately need to adopt systemd, or fall behind in a critical sub-system.
I think this is the basic problem. You take as obvious fact that traditional System V init simply has to go and the only questions are when, how and whether by systemd or something similar. I'm sorry but this isn't obvious to me at all.
I don't take that as obvious fact, not at all. To the contrary, I stated "If systemd is not emerging . . . ". Please read my entire post.
[snip]
There never was an actual discussion whether the transition should take place. People behind systemd keep pretending that it is so obvious that there is no need for such discussion. I don't agree. Before we talk about "when" and "how", the "if at all" discussion definitely should take place.
That is one of my two main points.
Hubert Mantel wrote:
After updating two of my machines to 12.1, I noticed that the systems sometimes come up with the network down (only loopback interface is up). Entering "rcnetwork restart" as root only yields the output "redirecting to systemd", but the network still is down. Since my children do not have the root password on their machine, they simply would power cycle the machine so often until the network finally works.
Some colleagues attributed my problems to the fact that I'm using static addresses and not dhcp. But nobody has an idea what the real problem is, nobody can give me a hint how to debug it.
I consider a system that comes up correctly only with a probability of around 70% as utterly broken.
Of course I filed a bug report weeks ago, but nobody seems to have an idea.
Finally I dropped systemd and replaced it by sysvinit-init and all my problems are gone.
I also had that problem on 2 systems. I filed a bug report and switched back to sysv too. The other computer, which doesn't have this problem, uses network manager to run networking.
Hubert Mantel mantel@suse.de wrote:
Hi,
On Mon, Feb 06, Joerg Schilling wrote:
I can contribute some technical criticism: systemd is unreliable!
So why not using SMF instead?
What are you referring to?
Well, I would expect that someone who likes to discuss the area of init successors knows SMF (service management facility).
SMF is the implementation that automatically creates a dependency graph and thus allows to automatically start services concurrently if there are no dependencies.
Jörg
James Knott wrote:
Finally I dropped systemd and replaced it by sysvinit-init and all my problems are gone.
I also had that problem on 2 systems. I filed a bug report and switched back to sysv too. The other computer, which doesn't have this problem, uses network manager to run networking.
Sorry, forgot the bug link: https://bugzilla.novell.com/show_bug.cgi?id=736108
* Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de [2012-02-06 14:15]:
Hubert Mantel mantel@suse.de wrote:
Hi,
On Mon, Feb 06, Joerg Schilling wrote:
I can contribute some technical criticism: systemd is unreliable!
So why not using SMF instead?
What are you referring to?
Well, I would expect that someone who likes to discuss the area of init successors knows SMF (service management facility).
SMF is the implementation that automatically creates a dependency graph and thus allows to automatically start services concurrently if there are no dependencies.
I would expect that someone who posts on an openSUSE list knows that openSUSE sysvinit is already capable of that.
Anyway, I'm looking forward to your Linux port of SMF since it works quite well for me on Solaris.
Guido Berhoerster gber@opensuse.org wrote:
Well, I would expect that someone who likes to discuss the area of init successors knows SMF (service management facility).
SMF is the implementation that automatically creates a dependency graph and thus allows to automatically start services concurrently if there are no dependencies.
I would expect that someone who posts on an openSUSE list knows that openSUSE sysvinit is already capable of that.
It is most unlikely that init on Suse does all what SMF can do, as there is also the capability of detecting died services even in case these services did double fork...
Also for automated concurrency, you need data structures that describe dependencies, do they exist already?
Anyway, I'm looking forward to your Linux port of SMF since it works quite well for me on Solaris.
I believe that this port is trivial once the contract filesystem has been ported.
Jörg
Le lundi 06 février 2012 à 08:33 -0500, James Knott a écrit :
James Knott wrote:
Finally I dropped systemd and replaced it by sysvinit-init and all my problems are gone.
I also had that problem on 2 systems. I filed a bug report and switched back to sysv too. The other computer, which doesn't have this problem, uses network manager to run networking.
Sorry, forgot the bug link: https://bugzilla.novell.com/show_bug.cgi?id=736108
You realize this bug report has nothing to do with systemd vs sysvinit ?
On Mon, Feb 6, 2012 at 11:08 AM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
I would expect that someone who posts on an openSUSE list knows that openSUSE sysvinit is already capable of that.
It is most unlikely that init on Suse does all what SMF can do, as there is also the capability of detecting died services even in case these services did double fork...
That's what all the talk about ExecStatus was all about. And yes, openSUSE init scripts can detect dead services quite reliably, at least in my limited experience, as most of them do further checks beyond just verifying a pid file.
Also for automated concurrency, you need data structures that describe dependencies, do they exist already?
It's there already. It's part of the LSB spec, btw. Debian link[0]
[0] http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
Hi,
On Mon, Feb 06, Joerg Schilling wrote:
So why not using SMF instead?
What are you referring to?
Well, I would expect that someone who likes to discuss the area of init successors knows SMF (service management facility).
I'm not interested in such discussions, in fact I'm mostly interested in dealing with NAP.
I just wanted to point out that there _are_ technical critics on systemd: For me, systemd is broken and sysvinit works. Being pragmatic, I dropped systemd and now have working systems. I gave systemd a try for more than a month and came to the conclusion that it is not ready for production use.
Case closed.
Jörg
Hubert Mantel
On Mon 06 Feb 2012 10:39:34 AM EST, Hubert Mantel wrote:
Hi,
On Mon, Feb 06, Joerg Schilling wrote:
So why not using SMF instead?
What are you referring to?
Well, I would expect that someone who likes to discuss the area of init successors knows SMF (service management facility).
I'm not interested in such discussions, in fact I'm mostly interested in dealing with NAP.
I just wanted to point out that there _are_ technical critics on systemd: For me, systemd is broken and sysvinit works. Being pragmatic, I dropped systemd and now have working systems. I gave systemd a try for more than a month and came to the conclusion that it is not ready for production use.
Case closed.
Jörg
Hubert Mantel
Can we agree that the transition is NOT 100% complete? It may take another version or two.
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
Everyone in this community (meaning the wider FLOSS community here), esp. everyone actively putting work into any part of it, wants to be productive and do something positive for this world. We all might have different views of what's the best ways to go on certain things, but we're all trying to make things better from our own point of view and work hard on that. Personal attacks have no space in such an environment.
If you want to be taken seriously by other people on this list or in any other similar setting, you need to talk in "how can this issue be solved" and not in "this is crap" and/or "you suck" terms. If you can't do that, you will never be happy in those communities, and they will never be happy about you. So please restrain yourself and learn how to argue constructively. There's enough destructiveness in this world that we better make this place a constructive one.
That said, standard Linux has shown pretty clearly in the last couple of years that it needs a change in the basic boot and process/system management field. OK, we're doing pretty OK in servers, but they don't need a lot in this area, being rarely rebooted and rarely changing what they are doing, so the same main processes stay up and spawn whatever helpers they need and that's it. In the desktop and mobile fields though, the major competitors outperform us in just about everything in that space - booting _way_ faster (esp. Win7 is pretty good there), having first-class management of system/background services, etc.
If we want to compete in those areas, we need solutions there, and it has been pretty hard to get sysvinit in shape for any of that. It looks like most distribution maintainers at a higher level agree that the ideas that systemd is being based on look like a good base for solving a lot in this space. Yes, it's painful to switch something so deep in our stack and there will be some cases where there's some work needed to get things to work with systemd that had been working with sysvinit, but switching back on those systems is likely only a temporary solution and only pushes out the problem instead of solving it. Let's work together to find solutions.
We all want Linux, esp. openSUSE, to be successful, and so we need to bite the bullet and find ways to make us competitive so we can attract people to use those systems. One way to get there is to improve systemd enough to cover all cases we need. If you feel systemd is not a good base for solving the problems, try finding an alternative that can fix both not being competitive in those areas _and_ the problems you see in systemd, and maybe what comes out of this is even better. People are surely open to that.
Still, don't attack others, but work with them to find solutions even more people can be happy with.
Robert kaiser
On Mon 06 Feb 2012 12:17:49 PM EST, Robert Kaiser wrote:
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
Everyone in this community (meaning the wider FLOSS community here), esp. everyone actively putting work into any part of it, wants to be productive and do something positive for this world. We all might have different views of what's the best ways to go on certain things, but we're all trying to make things better from our own point of view and work hard on that. Personal attacks have no space in such an environment.
If you want to be taken seriously by other people on this list or in any other similar setting, you need to talk in "how can this issue be solved" and not in "this is crap" and/or "you suck" terms. If you can't do that, you will never be happy in those communities, and they will never be happy about you. So please restrain yourself and learn how to argue constructively. There's enough destructiveness in this world that we better make this place a constructive one.
That said, standard Linux has shown pretty clearly in the last couple of years that it needs a change in the basic boot and process/system management field. OK, we're doing pretty OK in servers, but they don't need a lot in this area, being rarely rebooted and rarely changing what they are doing, so the same main processes stay up and spawn whatever helpers they need and that's it. In the desktop and mobile fields though, the major competitors outperform us in just about everything in that space - booting _way_ faster (esp. Win7 is pretty good there), having first-class management of system/background services, etc.
If we want to compete in those areas, we need solutions there, and it has been pretty hard to get sysvinit in shape for any of that. It looks like most distribution maintainers at a higher level agree that the ideas that systemd is being based on look like a good base for solving a lot in this space. Yes, it's painful to switch something so deep in our stack and there will be some cases where there's some work needed to get things to work with systemd that had been working with sysvinit, but switching back on those systems is likely only a temporary solution and only pushes out the problem instead of solving it. Let's work together to find solutions.
We all want Linux, esp. openSUSE, to be successful, and so we need to bite the bullet and find ways to make us competitive so we can attract people to use those systems. One way to get there is to improve systemd enough to cover all cases we need. If you feel systemd is not a good base for solving the problems, try finding an alternative that can fix both not being competitive in those areas _and_ the problems you see in systemd, and maybe what comes out of this is even better. People are surely open to that.
Still, don't attack others, but work with them to find solutions even more people can be happy with.
Robert kaiser
+1+1
On Mon, Feb 6, 2012 at 6:51 AM, Sven Burmeister sven.burmeister@gmx.net wrote:
I think you misunderstood. AFAIU Cristian wants to remove those scripts in case systemd is used. He does not care about what you do if you operate sysvinit.
If Cristian means that, he should say that. He has instead said he wants to see the rpmlint packaging rules modified to enforce /etc/init.d/* be an illegal directory on all openSUSE packages.
That is a very strong and anti-sysVinit rule.
I'm personally not against moving to pure systemd if and when the distro is ready, but to claim Cristian proposed anything shy of killing off sysVinit is not dealing with the RFC as written.
Greg
-- Greg Freemyer Head of EDD Tape Extraction and Processing team Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev...
The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com
On Monday, February 06, 2012 12:17 PM Robert Kaiser wrote:
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
Everyone in this community (meaning the wider FLOSS community here), esp. everyone actively putting work into any part of it, wants to be productive and do something positive for this world. We all might have different views of what's the best ways to go on certain things, but we're all trying to make things better from our own point of view and work hard on that. Personal attacks have no space in such an environment.
If you want to be taken seriously by other people on this list or in any other similar setting, you need to talk in "how can this issue be solved" and not in "this is crap" and/or "you suck" terms. If you can't do that, you will never be happy in those communities, and they will never be happy about you. So please restrain yourself and learn how to argue constructively. There's enough destructiveness in this world that we better make this place a constructive one.
That said, standard Linux has shown pretty clearly in the last couple of years that it needs a change in the basic boot and process/system management field. OK, we're doing pretty OK in servers, but they don't need a lot in this area, being rarely rebooted and rarely changing what they are doing, so the same main processes stay up and spawn whatever helpers they need and that's it. In the desktop and mobile fields though, the major competitors outperform us in just about everything in that space - booting _way_ faster (esp. Win7 is pretty good there), having first-class management of system/background services, etc.
If we want to compete in those areas, we need solutions there, and it has been pretty hard to get sysvinit in shape for any of that. It looks like most distribution maintainers at a higher level agree that the ideas that systemd is being based on look like a good base for solving a lot in this space. Yes, it's painful to switch something so deep in our stack and there will be some cases where there's some work needed to get things to work with systemd that had been working with sysvinit, but switching back on those systems is likely only a temporary solution and only pushes out the problem instead of solving it. Let's work together to find solutions.
We all want Linux, esp. openSUSE, to be successful, and so we need to bite the bullet and find ways to make us competitive so we can attract people to use those systems. One way to get there is to improve systemd enough to cover all cases we need. If you feel systemd is not a good base for solving the problems, try finding an alternative that can fix both not being competitive in those areas _and_ the problems you see in systemd, and maybe what comes out of this is even better. People are surely open to that.
Still, don't attack others, but work with them to find solutions even more people can be happy with.
Robert kaiser
+1!
Le lundi 06 février 2012, à 18:17 +0100, Robert Kaiser a écrit :
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
Obvious +1 on this.
But let me hijack your good comment with a request to everybody keeping this thread alive: the discussion doesn't bring anything useful anymore now. We just hear the same points again and again. When a decision will have to be taken, it will be taken by the people involved in the area (including systemd and sysvinit package maintainers) and the release team [1].
So can we stop this thread now? And in general, can we try to stop keeping alive threads when it's obvious they don't bring anything anymore?
Thanks,
Vincent
[1] http://en.opensuse.org/openSUSE:Release_team
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2012-02-06 at 11:58 -0500, Roman Bysh wrote:
Can we agree that the transition is NOT 100% complete? It may take another version or two.
Yes, I can. But as a consequence of that, sysvinit can not be phased out now, as this rfc proposes. The proposal is moot :-)
- -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2012-02-06 at 18:17 +0100, Robert Kaiser wrote:
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
That's true.
- -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On 2/6/2012 2:23 PM, Vincent Untz wrote:
Le lundi 06 février 2012, à 18:17 +0100, Robert Kaiser a écrit :
Ruediger Meier schrieb:
Yes it's a personal attack. But he deserves it.
Hold on. NOBODY _deserves_ personal attacks.
Obvious +1 on this.
But let me hijack your good comment with a request to everybody keeping this thread alive: the discussion doesn't bring anything useful anymore now. We just hear the same points again and again. When a decision will have to be taken, it will be taken by the people involved in the area (including systemd and sysvinit package maintainers) and the release team [1].
So can we stop this thread now? And in general, can we try to stop keeping alive threads when it's obvious they don't bring anything anymore?
Why? Has the risk of my system getting F*'ed up gone away? No? Then why should I stop saying I don't want it?
There are three main problems (for me) with systemd. Two are technical and solvable. The other is personal and not.
Tech problem 1: A system based on scripts is infinitely more flexible, transparent, debugable, than a system based on a binary compiled c program. That has uncountable value and I want that. And bonus, we already have it. Why throw it away?
Tech problem 2: ExecStatus. Systemd appears to be fundamentaly event driven, it reacts to trigge