[opensuse-factory] How many init systems openSUSE needs?
Hallo, At the moment we have two different init systems - the previous old sysvinit and the new one systemd, which is the default one since 12.1. As my hackweek project is very connected into boot, I've discovered this situation ends in a fact that we do not have a good support for sysvinit neither systemd. Few examples: * there is a lot of overlapping between sysv scripts we still use and systemd - systemd-modules-load.service versus /etc/init.d/boot.loadmodules from mkinitrd noone catched because LSB scripts "just works" with systemd * on the other hand Marcus Meissner found several issues in sysvinit support shows a big lack of a testing, because systemd is the default one I do not believe that extending the "transition period" for one, or more openSUSE releases will make anything better. In fact it will extend the painfull perior when systemd-lovers will be upset by a taking a care about the old sysvinit way and sysvinit lovers will feels like second-class citizens in the new world. And that's a perfect example of no-win situation [1]. Therefor I am convinced we as openSUSE community have to 1.) decide 2.) make the winner system the default one and the best one 3.) in case there will be a strong community willing to support the second system from the contest, let invent a way how they can do that. With all great features we have (zypp, OBS) it won't be so hard. I am not sure is how to make such decision in openSUSE community. Would we use FATE voting for that? Or find some dictator/board who will decide? BTW: I hope that you will discuss how many init system we need and in case one is the answer, how to make the decision. Having the last flamewar [2] in a mind, I'd like to have a fire suit. [1] http://en.wikipedia.org/wiki/No-win_situation [2] http://opensuse.14.n6.nabble.com/RFC-DRAFT-Phasing-out-sysvinit-tt3355356.ht... Regards Michal Vyskocil
On Tue, Jul 24, 2012 at 5:42 AM, Michal Vyskocil <mvyskocil@suse.cz> wrote:
I do not believe that extending the "transition period" for one, or more openSUSE releases will make anything better.
I hope I'm not feeding the troll, but experience has shown that one release cycle wasn't enough to make systemd server-worthy. I say server, because most (yet not all) of the bugs reported affected servers. Because systemd seems to have concentrated on desktop functionality, and lacks many features server sysadmins need. So... IMO, this is wishful thinking, and closing the transition period before systemd is server-worthy is burying one's head in the sand. Killing systemd is unlikely to happen, so we're left with this situation of multiple init systems. If you ask me, this is good. Packagers are spoiled in thinking there's only one init system, and the machinery that will inevitably grow to handle the two init systems will be a good thing for openSUSE's packaging process in general. It's like, in programming, splitting an ill-conceived monolithic app into well defined modules - a pain at the beginning, but a huge benefit in the end. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 24/07/12 10:46, Claudio Freire escribió:
I say server, because most (yet not all) of the bugs reported affected servers. Because systemd seems to have concentrated on desktop functionality, and lacks many features server sysadmins need.
which bugs ?
If you ask me, this is good.
No, it is not, at least not good for packagers and people that in general have to keep up with this always changing ecosystem. Having two init systems is completely fricking insane, just like it was 6 months ago, no news here, having this topic raised again is just a symptom of it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 24, 2012 at 12:28 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
If you ask me, this is good.
No, it is not, at least not good for packagers and people that in general have to keep up with this always changing ecosystem.
Having two init systems is completely fricking insane, just like it was 6 months ago, no news here, having this topic raised again is just a symptom of it.
Why not? Everything in linux is swappable. Windowing systems are. GUIs are. Why are init systems not swappable? I know a distro picks an init system and sticks to it... but that's only because the tools to make init systems easily swappable are lacking. Mantaining two init systems will just make those tools evolve. Is that not good? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 7/24/2012 11:34 AM, Claudio Freire wrote:
On Tue, Jul 24, 2012 at 12:28 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
If you ask me, this is good.
No, it is not, at least not good for packagers and people that in general have to keep up with this always changing ecosystem.
Having two init systems is completely fricking insane, just like it was 6 months ago, no news here, having this topic raised again is just a symptom of it.
Why not?
Everything in linux is swappable. Windowing systems are. GUIs are. Why are init systems not swappable?
I know a distro picks an init system and sticks to it... but that's only because the tools to make init systems easily swappable are lacking. Mantaining two init systems will just make those tools evolve. Is that not good?
Haha welcome to CF world... You could take many of his statements and swap the bad tech idea of the moment for the word Jesus and it would fit perfectly. I prove not to be merely the same in reverse by saying I would love the process you described if it's feasible. I'm not _sure_ it is feasible, but if it is it would absolutely be worth the pain to attain. There are certain standards that most gui apps and windowing systems share that makes them swappable. I'm not sure the init system can be so swappable the same way, because the individual apps would all need to support some kind of new standard but I think it's worth the effort to find out. Personally I think systemd could and should coexist with sysvinit the same way xinetd does. With xinetd, you can start a service like ftpd either by having an init script that starts it directly, or by having an xinetd config file. Sysv init either manages ftpd, or manages xinetd and xinetd manages ftpd. You can even have support for both options on the same system at the same time and yast can even keep track of them and prevent both from trying to be active at the same time. So I would be fine with that arrangement, where sysv init is still THE init, and systemd is one of the services sysv init starts and stops. With a little work putting common names on some capabilities, yast et al could pretty easily keep track for example that only one cron-provider is active at a time, whether it's systemd's built-in or a stand-alone, even though they have different package names. If someone really wants to leverage the supposed benefits of having systemd manage the entire system directly and exclusively, ie no sysv init even installed, I'm sure with some work a way can be figured out to allow that option too. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 24, 2012 at 02:45:34PM -0400, Brian K. White wrote:
On 7/24/2012 11:34 AM, Claudio Freire wrote:
Personally I think systemd could and should coexist with sysvinit the same way xinetd does.
Hallo Brian, Are you really convinced adding a new complex way of controlling your services is a way to go?
With xinetd, you can start a service like ftpd either by having an init script that starts it directly, or by having an xinetd config file. Sysv init either manages ftpd, or manages xinetd and xinetd manages ftpd. You can even have support for both options on the same system at the same time and yast can even keep track of them and prevent both from trying to be active at the same time.
In fact one of the basic concepts of systemd is make it only one part of a system executing and controlling services. That means things done atm by xinetd, cron, icron, dbus, desktop-session, whatever will be handled by systemd (not everything by PID 1, but by the same code) as one central place. I like that very much, because it makes the service configuration independent on a type of activation. And of course, you have the same set of kernel features available everywhere.
So I would be fine with that arrangement, where sysv init is still THE init, and systemd is one of the services sysv init starts and stops. With a little work putting common names on some capabilities, yast et al could pretty easily keep track for example that only one cron-provider is active at a time, whether it's systemd's built-in or a stand-alone, even though they have different package names.
How would poor yast ensure you can't do both sh /etc/inid./vsftpd start and systemctl start vsftpd.service? Regards Michal Vyskocil
On Wednesday 25 July 2012, Michal Vyskocil wrote:
On Tue, Jul 24, 2012 at 02:45:34PM -0400, Brian K. White wrote:
On 7/24/2012 11:34 AM, Claudio Freire wrote:
Personally I think systemd could and should coexist with sysvinit the same way xinetd does.
Hallo Brian,
Are you really convinced adding a new complex way of controlling your services is a way to go?
With xinetd, you can start a service like ftpd either by having an init script that starts it directly, or by having an xinetd config file. Sysv init either manages ftpd, or manages xinetd and xinetd manages ftpd. You can even have support for both options on the same system at the same time and yast can even keep track of them and prevent both from trying to be active at the same time.
In fact one of the basic concepts of systemd is make it only one part of a system executing and controlling services. That means things done atm by xinetd, cron, icron, dbus, desktop-session, whatever will be handled by systemd (not everything by PID 1, but by the same code) as one central place.
This concept is exactly why systemd will never co-exist friendly on a unix like system where different tasks are done by small "swappable" tools.
I like that very much, because it makes the service configuration independent on a type of activation. And of course, you have the same set of kernel features available everywhere.
Systemd is for linux only. You will find it nowhere else. Moreover it makes you even more unfree about many details how to configure your system as you want. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Jul 25, 2012 at 12:23:18PM +0200, Ruediger Meier wrote:
On Wednesday 25 July 2012, Michal Vyskocil wrote:
On Tue, Jul 24, 2012 at 02:45:34PM -0400, Brian K. White wrote:
On 7/24/2012 11:34 AM, Claudio Freire wrote:
Personally I think systemd could and should coexist with sysvinit the same way xinetd does.
Hallo Brian,
Are you really convinced adding a new complex way of controlling your services is a way to go?
With xinetd, you can start a service like ftpd either by having an init script that starts it directly, or by having an xinetd config file. Sysv init either manages ftpd, or manages xinetd and xinetd manages ftpd. You can even have support for both options on the same system at the same time and yast can even keep track of them and prevent both from trying to be active at the same time.
In fact one of the basic concepts of systemd is make it only one part of a system executing and controlling services. That means things done atm by xinetd, cron, icron, dbus, desktop-session, whatever will be handled by systemd (not everything by PID 1, but by the same code) as one central place.
This concept is exactly why systemd will never co-exist friendly on a unix like system where different tasks are done by small "swappable" tools.
Hallo, Why do you think that? Systemd can coexist with such services - if you want to, you still can run your cron.service, icron.service or xinetd.service if you want to. However the goal is to make those services obsoleted, which is definitelly true for later two. And to provide one central point for controlling of all (OK, things started from user shell session does not count) your processes. On the other hand it is true that coexisting with /sbin/init won't be friendly. But the main reason is the complexity of the resulted system, not the (un)friendliness of any involved tool.
I like that very much, because it makes the service configuration independent on a type of activation. And of course, you have the same set of kernel features available everywhere.
Systemd is for linux only. You will find it nowhere else. Moreover it makes you even more unfree about many details how to configure your system as you want.
I do not agree with you - if you maintain more systems, you have to deal with a tons of differences as well. You have iptables, where others have pf/ipwf/whatever system? Without learning all those systems, you weren't be able to even secure your system. Or other nixes have ifconfig, but ip is more suitable tool for Linux. Or they have still inetd, but SUSE have xinetd. Or some systems have a BSD like style with /etc/rc.conf, where SUSE have /etc/sysconfig. Or on some systems you have to deal with /etc/rc*/ symlinks manually, but I don't say that can be recommended for SUSE or other Linux systems. So all systems were, are and will be different even in very core parts and you have to be aware about them. Systemd is not an exception. You will have to learn how to configure it if you will have to maintain systemd-powered server. Regards Michal Vyskocil
Le mardi 24 juillet 2012 à 11:46 -0300, Claudio Freire a écrit :
On Tue, Jul 24, 2012 at 5:42 AM, Michal Vyskocil <mvyskocil@suse.cz> wrote:
I do not believe that extending the "transition period" for one, or more openSUSE releases will make anything better.
I hope I'm not feeding the troll, but experience has shown that one release cycle wasn't enough to make systemd server-worthy.
I say server, because most (yet not all) of the bugs reported affected servers. Because systemd seems to have concentrated on desktop functionality, and lacks many features server sysadmins need.
If features are missing for sysadmins, please ask for them (with a rationale, it is even better) on systemd mailing list. If there are bugs remaining, open bug reports. And of course, I wouldn't mind some help in fixing bugs too.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 24, 2012 at 2:02 PM, Frederic Crozat <fcrozat@suse.com> wrote:
If features are missing for sysadmins, please ask for them (with a rationale, it is even better) on systemd mailing list. If there are bugs remaining, open bug reports.
I did. There were bug reports, I didn't start them. Not gonna dig them up, systemd guys (not sure if they were the authors, the maintainers or what) made it clear they weren't interested in implementing them. Everything's in the archives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/24/2012 07:07 PM, Claudio Freire wrote:
On Tue, Jul 24, 2012 at 2:02 PM, Frederic Crozat <fcrozat@suse.com> wrote:
If features are missing for sysadmins, please ask for them (with a rationale, it is even better) on systemd mailing list. If there are bugs remaining, open bug reports.
I did. There were bug reports, I didn't start them. Not gonna dig them up, systemd guys (not sure if they were the authors, the maintainers or what) made it clear they weren't interested in implementing them. Everything's in the archives.
Please give a pointer to those that you consider critical, otherwise we cannot reevaluate them. Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jul 24, 2012 at 11:46:37AM -0300, Claudio Freire wrote:
On Tue, Jul 24, 2012 at 5:42 AM, Michal Vyskocil <mvyskocil@suse.cz> wrote:
I do not believe that extending the "transition period" for one, or more openSUSE releases will make anything better.
I hope I'm not feeding the troll, but experience has shown that one release cycle wasn't enough to make systemd server-worthy.
I say server, because most (yet not all) of the bugs reported affected servers. Because systemd seems to have concentrated on desktop functionality, and lacks many features server sysadmins need.
Hallo Claudio, I honestly disagree, as I faced a lot of systemd bugs in a past on my desktop. Anyway the "lacking features part" have to follow the list of things cannot be handled by systemd - I doubt there are any others than this is done differently than before, or this one particular hackish script do not boot (call it suse-network-scripts-syndromme ;-). But I can be wrong, so the best way how to correct me is list of issues, you've reported and I'll shut up immediatelly ;-)
So... IMO, this is wishful thinking, and closing the transition period before systemd is server-worthy is burying one's head in the sand. Killing systemd is unlikely to happen, so we're left with this situation of multiple init systems.
Unfortunatelly current situation is very bad from sysvinit and systemd point of view as we do not have a good support for anyone. I am convinced the transition period did not succeeded, mainly because most of people facing a problem with systemd switched back to sysv - that makes all problems hidden to us. So I vote for making a period over, decide, let people affected by systemd report their bug and in case they all won't be fixed in next openSUSE release, add it to release notes, so people will be informed and can switch this release.
If you ask me, this is good. Packagers are spoiled in thinking there's only one init system, and the machinery that will inevitably grow to handle the two init systems will be a good thing for openSUSE's packaging process in general. It's like, in programming, splitting an ill-conceived monolithic app into well defined modules - a pain at the beginning, but a huge benefit in the end.
Did you say having two init systems is good because it enhance a modularity? Or I'm completelly wrong? Regards Michal Vyskocil
participants (7)
-
Andreas Jaeger -
Brian K. White -
Claudio Freire -
Cristian Rodríguez -
Frederic Crozat -
Michal Vyskocil -
Ruediger Meier