[opensuse-factory] [RFC] sysvinit: plan B
Hallo all, Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future. It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd. Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init %post %{inserv ... The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now. The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases. But in anycase, the future is in your hands ... BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you Regards Michal Vyskocil
On Fri, Sep 7, 2012 at 10:43 AM, Michal Vyskocil <mvyskocil@suse.cz> wrote:
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Seems to me like a good move, if someone will move all current sysvinit packages to that project (so that people don't start from scratch). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.09.2012 17:55, schrieb Claudio Freire:
Seems to me like a good move, if someone will move all current sysvinit packages to that project (so that people don't start from scratch).
However, we need a way to tell that the system is using sysvinit when filing bugreports, so that the bugs can be dealt with accordingly. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 07/09/12 10:43, Michal Vyskocil escribió:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Thanks for proving my point, when it comes to complain and obstruct, we get hundred of replies, but when push come to shove, that is, getting stuff done and moving forward, crickets can be heard in the distance. In short, to summarize the opossition "I dont want to understand how it works I am lazy and resistant to change, therefore it is bad... oh and btw you are obtuse prick and the systemd authors are too". Now, let's continue moving to the goal of removing sysvinit and focus in a single solution instead. Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Cristian Rodríguez <crrodriguez@opensuse.org> writes:
El 07/09/12 10:43, Michal Vyskocil escribió:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Thanks for proving my point, when it comes to complain and obstruct, we get hundred of replies, but when push come to shove, that is, getting stuff done and moving forward, crickets can be heard in the distance.
In short, to summarize the opossition
"I dont want to understand how it works I am lazy and resistant to change, therefore it is bad... oh and btw you are obtuse prick and the systemd authors are too".
Here's a better summary: I am responsible for <X> boxes of <Y> vendors, and hence <Y+foo> proprietary solutions for <Z> that would need extensive fiddling with. I started migrating a few test boxes and it turned out to be a disaster. On top of that, it seems nobody in the community is able/willing to solve *MY* particular problems. Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, September 14, 2012 06:35:06 Sebastian Freundt wrote:
Cristian Rodríguez <crrodriguez@opensuse.org> writes:
El 07/09/12 10:43, Michal Vyskocil escribió:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Thanks for proving my point, when it comes to complain and obstruct, we get hundred of replies, but when push come to shove, that is, getting stuff done and moving forward, crickets can be heard in the distance.
In short, to summarize the opossition
"I dont want to understand how it works I am lazy and resistant to change, therefore it is bad... oh and btw you are obtuse prick and the systemd authors are too".
Here's a better summary:
I don't agree with that summary.
I am responsible for <X> boxes of <Y> vendors, and hence <Y+foo> proprietary solutions for <Z> that would need extensive fiddling with.
What kind of fiddling would be needed? We continue to support LSB init scripts.
I started migrating a few test boxes and it turned out to be a disaster. On top of that, it seems nobody in the community is able/willing to solve *MY* particular problems.
The one problem raised in this discussion was the "VMware problem" where its difficult to get a status via systemd. As I've said, I asked Frederic to look into this once he's back from his vacation (next week). Did I miss any other of those "particular problems"? With 12.1 there were indeed some problems but those were fixed when reported - and I expect that remaining problems will get solved as well, 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 Fri, Sep 14, 2012 at 5:51 AM, Andreas Jaeger <aj@suse.com> wrote:
I started migrating a few test boxes and it turned out to be a disaster. On top of that, it seems nobody in the community is able/willing to solve *MY* particular problems.
The one problem raised in this discussion was the "VMware problem" where its difficult to get a status via systemd. As I've said, I asked Frederic to look into this once he's back from his vacation (next week).
Did I miss any other of those "particular problems"?
There's also the consoles problem, but I think it's being worked around already (albeit not perfectly), and script output on tty. (be it serial or graphic) I honestly haven't tried serial (the systems I have to control with serial I 1-rarely do, and 2-don't have systemd). But I've heard people complain about systemd being a lot more unfriendly than sysvinit with serial. And that's pretty much it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 14/09/12 11:27, Claudio Freire escribió:
I honestly haven't tried serial (the systems I have to control with serial I 1-rarely do, and 2-don't have systemd). But I've heard people complain about systemd being a lot more unfriendly than sysvinit with serial.
And that's pretty much it.
Serial console setup is described here http://0pointer.de/blog/projects/instances.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Sep 14, 2012 at 11:56 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
I honestly haven't tried serial (the systems I have to control with serial I 1-rarely do, and 2-don't have systemd). But I've heard people complain about systemd being a lot more unfriendly than sysvinit with serial.
And that's pretty much it.
Serial console setup is described here http://0pointer.de/blog/projects/instances.html
I believe the problem here wasn't whether getty worked on the serial, but that you couldn't see boot messages as they were happening. Which makes it even more difficult to debug stuff when something goes wrong remotely and you only got a serial console at your disposal. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 14 septembre 2012 à 12:25 -0300, Claudio Freire a écrit :
On Fri, Sep 14, 2012 at 11:56 AM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
I honestly haven't tried serial (the systems I have to control with serial I 1-rarely do, and 2-don't have systemd). But I've heard people complain about systemd being a lot more unfriendly than sysvinit with serial.
And that's pretty much it.
Serial console setup is described here http://0pointer.de/blog/projects/instances.html
I believe the problem here wasn't whether getty worked on the serial, but that you couldn't see boot messages as they were happening. Which makes it even more difficult to debug stuff when something goes wrong remotely and you only got a serial console at your disposal.
Will be fixed with recent (if 185 or later) release of systemd, which is providing "idle" service type, to ensure getty are started after all other services have finished their startup. Unfortunately, backporting this feature for 12.2 wasn't possible (too intrusive). -- 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 Thursday 13 Sep 2012 23:53:34 Cristian Rodríguez wrote:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
I would like to see a list of documented problems (eg bugs). not a list of emotional reactions to oppose the change complemented with statements that prove that people who make them do not understand systemd or refer to old issues... I would like the sysvinit supporters create bug entries in the meta bug for the migration... I said it before... and I repeat it... There is nobody forcing them to move with the progress... they can keep 12.2 until the end of time... democracy is the best system to kill a valid argument... regards, Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 14 September 2012, Alin M Elena wrote:
On Thursday 13 Sep 2012 23:53:34 Cristian Rodríguez wrote:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
I would like to see a list of documented problems (eg bugs). not a list of emotional reactions to oppose the change complemented with statements that prove that people who make them do not understand systemd or refer to old issues...
I would like the sysvinit supporters create bug entries in the meta bug for the migration... I said it before... and I repeat it... There is nobody forcing them to move with the progress... they can keep 12.2 until the end of time...
The only problem is that "sysvinit supporters" like me are just happy now because sysvinit works. Can't fill bug reports for something which I don't use and where I don't have any good reason why I should try it.
democracy is the best system to kill a valid argument...
If sysvinit will be removed one time then it was hopefully tested by people who have used systemd for more than just flipping open/close their laptops and wondering how fast and colored it awakes in 98% of all events ... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The only problem is that "sysvinit supporters" like me are just happy now because sysvinit works. Can't fill bug reports for something which I don't use and where I don't have any good reason why I should try it. so you oppose systemd without having any idea about systemd? if 12.2 fits your needs why the hell even bother to polute us with your ideas about 12.3?
with people like you for sure we would have been still living in a cave looking for fruits in forests... Fruits are very tasty, why the hell should we spend time hunting and cooking... Alin -- Without Questions there are no Answers! ______________________________________________________________________ Alin Marin ELENA Advanced Molecular Simulation Research Laboratory School of Physics, University College Dublin ---- Ardionsamblú Móilíneach Saotharlann Taighde Scoil na Fisice, An Coláiste Ollscoile, Baile Átha Cliath ----------------------------------------------------------------------------------- http://alin.elenaworld.net ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 14 September 2012, Alin M Elena wrote:
The only problem is that "sysvinit supporters" like me are just happy now because sysvinit works. Can't fill bug reports for something which I don't use and where I don't have any good reason why I should try it.
so you oppose systemd without having any idea about systemd? if 12.2 fits your needs why the hell even bother to polute us with your ideas about 12.3?
What are you talking about? Of course I have tested systemd - one time - like a lot of other software which I decided to not need / not try again.
with people like you for sure we would have been still living in a cave looking for fruits in forests... Fruits are very tasty, why the hell should we spend time hunting and cooking...
You can go hunting and cooking as you want but please don't tell me that meat is better than fruits so that fruits will be removed soon or at least always being cooked ... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012-09-14 10:45 (GMT+0100) Alin M Elena composed:
democracy is the best system to kill a valid argument...
Democracy is overrated. In democracy, 51 people get to tell 49 what they may do, must do, and must not do. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/09/12 06:45, Alin M Elena wrote:
democracy is the best system to kill a valid argument...
I do t think choosing the best system from a technical point of view requires democracy, science is not a democratic process. In this case, it is enough to withdraw resources and attention to the old init system and it will die.. because no one else is looking into it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
In IBM mainframes running VM you could specify an affinity for a given task. Could that solve the problem if you "allocate" X processors for that task? Andy -----Original Message----- From: Cristian Rodríguez <crrodriguez@opensuse.org> To: opensuse-factory <opensuse-factory@opensuse.org> Sent: Fri, 14 Sep 2012 15:52 Subject: Re: [opensuse-factory] [RFC] sysvinit: plan B On 14/09/12 06:45, Alin M Elena wrote:
democracy is the best system to kill a valid argument...
I do t think choosing the best system from a technical point of view requires democracy, science is not a democratic process. In this case, it is enough to withdraw resources and attention to the old init system and it will die.. because no one else is looking into it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le vendredi 14 septembre 2012 à 10:45 +0100, Alin M Elena a écrit :
On Thursday 13 Sep 2012 23:53:34 Cristian Rodríguez wrote:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
I would like to see a list of documented problems (eg bugs). not a list of emotional reactions to oppose the change complemented with statements that prove that people who make them do not understand systemd or refer to old issues...
I'd also like to get this list. So far, the main complain is the missing support for "StatusExec" in .service (which is something upstream say "it could be done ; services using it would be treated as second-class citizens, in many regards; I have some rough ideas"). -- 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 Friday 2012-09-07 15:43, Michal Vyskocil wrote [http://lists.opensuse.org/opensuse-factory/2012-09/msg00396.html]:
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
It would seem more advantageous to change the systemd package, and provide an extra binary there that reuses the parser code to give users the possibility to start/stop/restart programs using unit files in a non-systemd environment. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance. I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files. There are still too many situations where sysvinit is needed. Be it those arm systems with old kernels on which systemd does not run (and porting those patches is hard), or "dhcpcd eth0" that just hung on my 12.2's systemd trying to restart ntp.service also, we should try to keep Factory in a state that is always working. And change things in ways that could be easily reverted if needed. Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBhuEEACgkQSTYLOx37oWS7WwCgxZZeDjFxpQ2KingeGgJnqXla KnMAn3zVnRQ4An3BGoTd3X1othssQt6j =kIv2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25.09.2012 15:57, Bernhard M. Wiedemann wrote:
Please count me in to help with sysvinit maintenance. I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files.
That won't work as it will be impossible to say if the init script is maintained or not. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25.09.2012 15:57, Bernhard M. Wiedemann wrote:
also, we should try to keep Factory in a state that is always working. And change things in ways that could be easily reverted if needed.
This is unrelated to the plan B, right? Because less init systems make it easier to keep things working - in general. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 25/09/12 10:57, Bernhard M. Wiedemann escribió:
Please count me in to help with sysvinit maintenance. I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files.
That wont work anyway... or at least not for certain common scenarios.. let me explain you why. - Anything that uses networkmanager wont work with sysvinit - Anything that uses policykit wont work with sysvinit. - Anything gnome wont work with sysvinit. - anything that used ConsoleKit, wont work with sysvinit. A I have explained many times before, the effort of maintaining two init system is doomed to fail or extremely difficult to carry on.
or "dhcpcd eth0" that just hung on my 12.2's systemd trying to restart ntp.service
That's a bug that needs to be addressed -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Sep 25, 2012 at 03:57:22PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance.
Hallo Bernhard, it's cool to have someone is willing to do the work - anyway I do not want to work on sysvinit, I'm the one from the enemy camp ;-) So please take the chance and you can (at least try to) define things you like.
I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files.
As a maintainer of few things uses sysv/sysd things, I must say I will be much happier to not taking a care about sysv limitations.
There are still too many situations where sysvinit is needed. Be it those arm systems with old kernels on which systemd does not run (and porting those patches is hard),
JFI: but is there any use case to run factory or 12.3 on arm system with the old kernel not supported by systemd? Or have I missed the point? Regards Michal Vyskocil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 27.09.2012 17:03, schrieb Michal Vyskocil:
On Tue, Sep 25, 2012 at 03:57:22PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance.
Hallo Bernhard,
it's cool to have someone is willing to do the work - anyway I do not want to work on sysvinit, I'm the one from the enemy camp ;-) So please take the chance and you can (at least try to) define things you like.
OK. To better coordinate this work, I started http://en.opensuse.org/openSUSE:Sysvinit Feel free to add yourself as contributor there, add details on problems and/or solutions.
I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files.
As a maintainer of few things uses sysv/sysd things, I must say I will be much happier to not taking a care about sysv limitations.
Which limitations cause most trouble to you?
There are still too many situations where sysvinit is needed. Be it those arm systems with old kernels on which systemd does not run (and porting those patches is hard),
JFI: but is there any use case to run factory or 12.3 on arm system with the old kernel not supported by systemd? Or have I missed the point?
openSUSE Factory is the only openSUSE we build for arm(v5el) atm. There will be 12.2 for armv7 soon at least. LXC is another use-case where you can have a newer VM user-space on an older host kernel. Also, there are cases where it is hard to boot with an initrd because of boot/system constraints (coreboot, U-Boot, User-Mode-Linux, ...). People then just build the relevant drivers into their kernel. That is yet another thing we should not break. Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBkhAUACgkQSTYLOx37oWS29wCgv9IpEZsH2/qxL/p2GJs0s9I9 lFkAnRc9mXXiooRD5TtPwBqdxDl7yiJO =tyw5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/27/2012 06:51 PM, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.09.2012 17:03, schrieb Michal Vyskocil:
On Tue, Sep 25, 2012 at 03:57:22PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance.
Hallo Bernhard,
it's cool to have someone is willing to do the work - anyway I do not want to work on sysvinit, I'm the one from the enemy camp ;-) So please take the chance and you can (at least try to) define things you like.
OK. To better coordinate this work, I started http://en.opensuse.org/openSUSE:Sysvinit
It really does not make sense to do this, guys! An example: inittab is not used by systemd so on an systemd system, I propose to have an empty file with a few comments about systemd. The same will happen in other places. Supporting both is a lot of work, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 27.09.2012 20:42, schrieb Andreas Jaeger:
On 09/27/2012 06:51 PM, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.09.2012 17:03, schrieb Michal Vyskocil:
On Tue, Sep 25, 2012 at 03:57:22PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance.
Hallo Bernhard,
it's cool to have someone is willing to do the work - anyway I do not want to work on sysvinit, I'm the one from the enemy camp ;-) So please take the chance and you can (at least try to) define things you like.
OK. To better coordinate this work, I started http://en.opensuse.org/openSUSE:Sysvinit
It really does not make sense to do this, guys!
An example: inittab is not used by systemd so on an systemd system, I propose to have an empty file with a few comments about systemd. The same will happen in other places. Supporting both is a lot of work,
would it hurt, to keep the current content (actually less work than dropping it) and add a prominent comment on top telling users that "systemd does not use this file, see $URL for systemd configuration equivalents instead" and the URL should link/explain to users' typical tasks that were done with inittab like changing the default runlevel configuring a serial console + baud rate running custom programs and getting their output on tty9 getting a root shell on a tty without login (using rungetty) and ideally even how to tweak things that were tweakable via /etc/init.d/boot* scripts before. Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBktGsACgkQSTYLOx37oWRJMwCglJmbCryagPpCSHpQOeCGY9Cs pV4AnRfkEoyXyQlqYp5f6/8QNd5iNk/4 =dOf3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 27/09/12 17:17, Bernhard M. Wiedemann escribió:
and the URL should link/explain to users' typical tasks that were done with inittab like changing the default runlevel
"Runlevels are an obsolete concept which is implemented in systemd as a minimal compatibility layer on top of systemd targets. To switch to the equivalent of runlevel 3: ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target To switch to the equivalent of runlevel 5 ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target "
configuring a serial console + baud rate
"To configure a serial console follow the steps detailed here http://0pointer.de/blog/projects/instances.html In order to change the baud rate you have to copy /lib/systemd/system/serial-getty@.service to /etc/systemd/system and modify accordingly "
running custom programs and getting their output on tty9
No idea.
getting a root shell on a tty without login (using rungetty)
a root shell without login can be obtaining by enabling the "debug-shell" service.
and ideally even how to tweak things that were tweakable via /etc/init.d/boot* scripts before.
early boot scripts are still supported but such support is scheduled for removal in the following months. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 27 Sep 2012 21:31:05 -0300 Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 27/09/12 17:17, Bernhard M. Wiedemann escribió:
<snip>
running custom programs and getting their output on tty9
No idea.
<snip> Hi I have htop running on tty12 was fairly simple... see my systemd-htop-service package; https://build.opensuse.org/package/show?package=systemd-htop-service&project=home%3Amalcolmlewis%3ATESTING -- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop up 2 days 11:26, 3 users, load average: 0.27, 0.14, 0.08 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Malcolm <malcolm_lewis@bellsouth.net> [09-27-12 20:57]:
I have htop running on tty12 was fairly simple... see my systemd-htop-service package;
systemctl enable htop.service systemctl start htop.service systemctl status htop.service Sep 27 23:15:37 Crash sh[2958]: /bin/sh: /dev/tty12: Permission denied ?? -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 27 Sep 2012 23:18:18 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
* Malcolm <malcolm_lewis@bellsouth.net> [09-27-12 20:57]:
I have htop running on tty12 was fairly simple... see my systemd-htop-service package;
systemctl enable htop.service systemctl start htop.service systemctl status htop.service Sep 27 23:15:37 Crash sh[2958]: /bin/sh: /dev/tty12: Permission denied
?? Hi Did you look at the readme? Run udevadm trigger and retry.
-- Cheers Malcolm °¿° (Linux Counter #276890) openSUSE 12.2 (x86_64) Kernel 3.4.6-2.10-desktop up 2 days 14:00, 3 users, load average: 0.13, 0.06, 0.05 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Malcolm <malcolm_lewis@bellsouth.net> [09-27-12 23:30]:
On Thu, 27 Sep 2012 23:18:18 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
* Malcolm <malcolm_lewis@bellsouth.net> [09-27-12 20:57]:
I have htop running on tty12 was fairly simple... see my systemd-htop-service package;
systemctl enable htop.service systemctl start htop.service systemctl status htop.service Sep 27 23:15:37 Crash sh[2958]: /bin/sh: /dev/tty12: Permission denied
?? Did you look at the readme? Run udevadm trigger and retry.
you *know* that I didn't, male, much (*much*) over 15 23:20 Crash: ~ # udevadm trigger 23:45 Crash: ~ # systemctl start htop.service 23:46 Crash: ~ # systemctl status htop.service htop.service - Process view on a Virtual Terminal with htop. Loaded: loaded (/lib/systemd/system/htop.service; enabled) Active: active (running) since Thu, 27 Sep 2012 23:46:03 -0400; 4s ago Process: 2961 ExecStop=/bin/sh -c /usr/bin/clear > /dev/tty${HTOP_TTY} < //dev/tty${HTOP_TTY} (code=exited, //status=1/FAILURE) Main PID: 8604 (sh) CGroup: name=systemd:/system/htop.service ├ 8604 /bin/sh -c /usr/bin/htop d 1 P > /dev/tty12 < /dev/tty12 └ 8606 /usr/bin/htop d 1 P and it shows all 12 cpu's :^) tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Sep 27, 2012 at 06:51:17PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.09.2012 17:03, schrieb Michal Vyskocil:
On Tue, Sep 25, 2012 at 03:57:22PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance.
Hallo Bernhard,
it's cool to have someone is willing to do the work - anyway I do not want to work on sysvinit, I'm the one from the enemy camp ;-) So please take the chance and you can (at least try to) define things you like.
OK. To better coordinate this work, I started http://en.opensuse.org/openSUSE:Sysvinit
Feel free to add yourself as contributor there, add details on problems and/or solutions.
I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files.
As a maintainer of few things uses sysv/sysd things, I must say I will be much happier to not taking a care about sysv limitations.
Which limitations cause most trouble to you?
In my specific case, User=, Group= is awesome for Java software maintainer. For instance tomcat under sysvinit is started in so hacky way, because we have to do su. But you have to export variables to the process as well, so you have to parse the file, ... - many enterprise apps rely on such start ... which is hard to debug and understood. With systemd (even if it was never designed for Java software) I have been working with Fedora maintainer to cut it off, so only one script is needed to handle return code and change the wd. There's only one thing prevents me to go through pure-systemd approach and it's variable support in WorkingDirectory=.
There are still too many situations where sysvinit is needed. Be it those arm systems with old kernels on which systemd does not run (and porting those patches is hard),
JFI: but is there any use case to run factory or 12.3 on arm system with the old kernel not supported by systemd? Or have I missed the point?
openSUSE Factory is the only openSUSE we build for arm(v5el) atm. There will be 12.2 for armv7 soon at least.
LXC is another use-case where you can have a newer VM user-space on an older host kernel.
Sure, that'd be the problem - LXC guests expecting systemd will need newest kernel. On the other hand, upgrading host's kernel might be less work, than supporting nonsyv targets in near future. Even enterprise distros increase kernel version from time to time ;-)
Also, there are cases where it is hard to boot with an initrd because of boot/system constraints (coreboot, U-Boot, User-Mode-Linux, ...). People then just build the relevant drivers into their kernel. That is yet another thing we should not break.
Systemd does not require initrd at all - it requires some recent version of kernel + relevant userspace utils (util linux?) only. Regards Michal Vyskocil
participants (16)
-
Alin M Elena -
Andreas Jaeger -
Bernhard M. Wiedemann -
Claudio Freire -
Cristian Rodríguez -
Felix Miata -
Frederic Crozat -
gm1mqe＠aol.com -
Jan Engelhardt -
Malcolm -
Michal Vyskocil -
Patrick Shanahan -
Ruediger Meier -
Sebastian Freundt -
Stefan Seyfried -
Stephan Kulow