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

Cristian Rodríguez 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 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 Fri, Sep 14, 2012 at 5:51 AM, Andreas Jaeger 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

On Fri, Sep 14, 2012 at 11:56 AM, Cristian Rodríguez 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

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

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

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 To: opensuse-factory 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

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

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

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

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

On Thu, 27 Sep 2012 21:31:05 -0300 Cristian Rodríguez 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

On Thu, 27 Sep 2012 23:18:18 -0400 Patrick Shanahan wrote:

* Malcolm [09-27-12 20:57]:

...

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

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

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