On Fri, Sep 28, 2012 at 08:27:15AM -0300, Cristian Rodríguez wrote:

El 28/09/12 05:13, eddie escribió:

...

Is chkconfig now obselete?

Yes.

Dunno what you mean by "obsolete". It was a little helper script for people that didn't what t call insserv directly. So it was always kind of "obsolete". I don't know if it can be tweaked for systemd. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Sep 28, 2012 at 08:27:15AM -0300, Cristian Rodríguez wrote:

El 28/09/12 05:13, eddie escribió:

...

Is chkconfig now obselete?

Yes.

Then it must be removed. Please quote the drop request ID to this thread. As long as it is available it will be used. And I suggest to keep it in a working state. Cause chkconfig is what people know and use. It's the same as with yum. Pleople know it. But they don't know zypper. We need at least a hint when people try to use yum that they should try zypper. Better would be a simple wrapper which is able to perform the base commands. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

El 28/09/12 09:03, Andrea Turrini escribió:

2012/9/28 Cristian Rodríguez :

...

El 28/09/12 05:13, eddie escribió:

...

Is chkconfig now obselete?

Yes.

Just two questions: 1) Where is this documented? I have not seen it in the oS 12.2 release notes.

You can find a systemd chapter in the "current" documentation.

2) How can I enable a systemd service only in runlevel 3 and not in runlevel 5?

Runlevels exists as a compatibility "thin layer" on systemd, there are no native runlevels anymore. can you give an example of a service you want to disable in runlevel 5 but have it working in runlevel 3 ? as well the rationale for such thing ?

If I try by using "yast2 runlevel", expert mode,

Yast runlevel editor has not been updated to work with systemd yet. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

2012/9/28 Cristian Rodríguez :

El 28/09/12 09:03, Andrea Turrini escribió:

...

2012/9/28 Cristian Rodríguez :

...

El 28/09/12 05:13, eddie escribió:

...

Is chkconfig now obselete?

Yes.

Just two questions: 1) Where is this documented? I have not seen it in the oS 12.2 release notes.

You can find a systemd chapter in the "current" documentation.

No reference to chkconfig (a "grep chkconfig /usr/share/doc/manual/opensuse-manuals_en/cha.systemd.html" returns nothing; a grep for chkconfig in /usr/share/doc/manual/opensuse-manuals_en/ matches only cha.apache2.html, cha.nfs.html, and cha.tuning.kexec.html). So, again, where is the fact "chkconfig is now obsolete" documented? This time please give me the file available on my disk I can install from oS dvd containing the paragraph talking about "chkconfig is now obsolete", not just a generic reference to the systemd documentation that does not even mention the word "chkconfig".

...

2) How can I enable a systemd service only in runlevel 3 and not in runlevel 5?

Runlevels exists as a compatibility "thin layer" on systemd, there are no native runlevels anymore.

can you give an example of a service you want to disable in runlevel 5 but have it working in runlevel 3 ? as well the rationale for such thing ?

This is exactly the answer I expected from you. I repeat the part of my mail you removed in your reply: On 09/28/2012 02:03 PM, Andrea Turrini wrote:

In particular, for the second question, please give a concrete answer to the question such as a list of commands to obtain the wanted result (list of commands that should be included in the release notes).

So, again, how can I concretely enable a service in runlevel 3 and not in runlevel 5 using systemd service files and terminal commands? I do not want to give you a concrete example and a rationale since as you (read: systemd supporters) say that systemd is a fully compatible replacement of sysV-init and that init files should be removed and replaced by service files, the proposed problem has to have a solution that works for every possible service you are or you are not aware of, as happens with init files. And possibly a solution that has the same complexity as using chkconfig or a couple of clicks in yast. Or do you want that I use only services approved by systemd or with a rationale acknowledged by systemd's supporters?

...

If I try by using "yast2 runlevel", expert mode,

Yast runlevel editor has not been updated to work with systemd yet.

And where is this now broken behavior documented in the release-notes/documentation of oS 12.2? According to the chapter of oS 12.2 documentation you referred, I expect that by using yast runlevel in expert mode I can change as *I want* and as the interface allows me the services in each runlevel, as it worked for a long time. Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 09/29/2012 12:03 PM, Felix Miata wrote:

I've not checked, but I suspect mention of chkconfig would be found subsequent to 'zypper in sysvinit-init' as root, as there should be a man page for it then.

No. chkconfig comes from aaa_base package; it has a manpage where the word "systemd" does not appear. A "zgrep chkconfig /usr/share/man/man*/*" returns only ifservices.5.gz, boot.7.gz, daemon.7.gz, chkconfig.8.gz, and service.8.gz. Of these, only daemon (coming from systemd rpm) talks about chkconfig, where it is described how to integrate rpm .spec file in order to activate an unit given that the service is active according to sysV-init. Obviously no mention of the fact that chkconfig is obsolete or that now its functionality has been changed by systemd.

Systemd as of 12.2 is not a drop-in replacement for sysvinit.

Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Monday, October 01, 2012 13:05:44 Michael Schroeder wrote:

On Sat, Sep 29, 2012 at 01:45:33PM +0200, Andrea Turrini wrote:

...

A "zgrep chkconfig /usr/share/man/man*/*" returns only ifservices.5.gz, boot.7.gz, daemon.7.gz, chkconfig.8.gz, and service.8.gz. Of these, only daemon (coming from systemd rpm) talks about chkconfig, where it is described how to integrate rpm .spec file in order to activate an unit given that the service is active according to sysV-init. Obviously no mention of the fact that chkconfig is obsolete or that now its functionality has been changed by systemd.

I really don't see why the commonly used 'chkconfig <service> on|off' form should be obsolete. It should call systemctl to do the job (like it did with insserv).

Did you test it on your system? ;) It should already work fine if there's an init script: byrd:~ # chkconfig postfix Note: Forwarding request to 'systemctl is-enabled postfix.service'. enabled postfix on byrd:~ # chkconfig postfix on insserv: Note: sysvinit service postfix is shadowed by systemd postfix.service, Forwarding request to '/bin/systemctl --no-reload --root / enable postfix.service'. insserv: Forward service request to systemctl returned error status : 256 I'm not sure whether it works in general with native systemd configuration files... 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 28/09/12 09:03, Andrea Turrini escribió:

2012/9/28 Cristian Rodríguez :

...

El 28/09/12 05:13, eddie escribió:

...

Is chkconfig now obselete?

Yes.

Just two questions: 1) Where is this documented? I have not seen it in the oS 12.2 release notes. 2) How can I enable a systemd service only in runlevel 3 and not in runlevel 5? If I try by using "yast2 runlevel", expert mode, I am allowed to mark only 3 and not 5, but then 5 is enabled as well, when the service file is present (tried with rpcbind). If the service file is not present but only the init file is available, as for gpm, everything works as expected.

A native systemd unit is available here: http://pkgs.fedoraproject.org/cgit/gpm.git/tree/gpm.service We need to add it to our packages... copy it to /etc/systemd/system , then issue systemctl --system daemon-reload , systemctl enable gpm.service , systemctl restart gpm.service -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

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

On 2012-09-29 01:08, Cristian Rodríguez wrote:

...

A native systemd unit is available here:

http://pkgs.fedoraproject.org/cgit/gpm.git/tree/gpm.service

We need to add it to our packages...

copy it to /etc/systemd/system , then issue systemctl --system daemon-reload , systemctl enable gpm.service , systemctl restart gpm.service

So, with systemD the administrator has lost the power to choose the runleves a service runs?

No, it's just done in a different way. -- Per Jessen, Zürich (12.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

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

On 2012-09-29 09:46, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

So, with systemD the administrator has lost the power to choose the runleves a service runs?

No, it's just done in a different way.

- From the posts here I understand that yast doesn't handle it.

Yes, it does look like YaST wasn't considered when we moved to systemd. -- Per Jessen, Zürich (11.6°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2012-09-29 at 15:23 -0300, Cristian Rodríguez wrote:

El 29/09/12 13:36, Per Jessen escribió:

...

Yes, it does look like YaST wasn't considered when we moved to systemd.

the runlevel module (and yast in general) needs more developers in order to keep up with changes.

Or the changes slowed down. YaST is openSUSE flagship. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBpbxoACgkQtTMYHG2NR9UZ6ACfSOqtoOdtWqrMjnmpC8XXQMxq cdYAni8ZMs/1jbnnNR45y4NgKTZZLMsz =j/5o -----END PGP SIGNATURE-----

Carlos E. R. said the following on 09/28/2012 07:24 PM:

So, with systemD the administrator has lost the power to choose the runleves a service runs?

Yes, pretty much that same way that porpoises have lost the ability to farm corn and beans. "runlevels" is about as meaningful with systemD as corn and beans farming is to a porpoise. Its a completely different context; runlevels don't exist any more as a concept under SystemD. Services and groups of services do. If you want to think of it that way, there was a group of services that ran under runlevel 3 and a group that ran under runlevel 5 and if you drew a Venn diagram there was overlap. In the file there was sometimes a description of what the runlevels meant .... single user ... multi user ... networking ... GUI ... Focus in the services not the number. To use systemd effectively you've got to let go of the runlevel concept. -- One trend that bothers me is the glorification of stupidity, that the media is reassuring people it's all right not to know anything. That to me is far more dangerous than a little pornography on the Internet. - Carl Sagan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Rajko said the following on 09/29/2012 11:45 AM:

On Sat, 29 Sep 2012 08:23:22 -0400 Anton Aylward wrote:

...

To use systemd effectively you've got to let go of the runlevel concept.

As you explained in your post, it is actually just different naming with greater flexibility in some ways, but also lesser, or even missing functionality in other ways, as it was explained by other people.

No, that's not what I said. Its not just a different naming; any naming similarity is coincidental. Its structurally different. Yes, there is greater functionality. You perception of "lesser, or even missing functionality in other ways" is an artefact of your expectations. Please note: the sysvinit way was not always the way things were done, and when it was introduced it caused its own upheaval. Some of us were there and welcomed it as a rationalization of went before. SystemD is a necessary progression. Such changes have to be revolutionary. *ALL* Sysvinit did was run a series of scripts in linear sequence. They had limited 'awareness' and made no use of the UNIX communication methods between them such as pipes and UNIX Domain sockets. At best, a script could test for the existence or content of a file. There was little error recovery capability. SystemD replaces runLEVELS with what amounts to runSTATES. Yes, you can squint an treat see Sysvinit as some kind of 'state', but as I said it is about linear lists of on/off. SystemD is about trees and dependency graphs; conditions, necessary and sufficient, and much better (though in many cases not yet implemented) error handling *AND* *BRANCHING*. "Not yet implemented"? Well sysvinit as we know it today was not born full fledged like that when it first replaced the haphazard collection of specific scripts.

My complaint is that systemd proponents are too radical and too fast with little, or no understanding, that not everyone has their skills.

My first reaction is "So? What else is new"? Most innovations go though that cycle. Oh wait, there is this... <quote src="http://www.goodreads.com/quotes/88687-it-must-be-remembered-that-there-is-nothing-more-difficult"> “It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who gain by the new ones. ” ― Niccolò Machiavelli </quote>

Programmers are brilliant in juggling unbelievable amounts of symbols, but fall short in understanding that other can't do that for various reasons; no time, no training, brain properties in handling textual information, short and mid term memory, etc.

Everyone, every profession, has their strengths and shortcomings, their brilliant innovators and those who would gainsay them. Some more so than others.

Removing "init {0,1,2,3,5,6}" strings from systemd forces people to do what computers do better, to translate between strings, ie. old and new commands. How helpful is that?

Ah, the "have you stopped beating your wife" style or argument. What does '"init 3" really mean' on the one hand vs 'what does multi-user state' really mean?. The "init 3" seems more "Prestigious Jargon"[1] and Bafflement and less informative than "multi-user mode". Being unfamiliar with something doesn't make it wrong. Some things _are_ the wrong way of doing things, but your arguments are emotive[1]. [1] http://www.don-lindsay-archive.org/skeptic/arguments.html#jargon [2] http://www.don-lindsay-archive.org/skeptic/arguments.html#emotive -- Of all things, good sense is the most fairly distributed: everyone thinks he is so well supplied with it that even those who are the hardest to satisfy in every other respect never desire more of it than they already have. - Rene Descartes (1596-1650), Discours de la Methode (1637) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 9/28/2012 7:24 PM, Carlos E. R. wrote:

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

On 2012-09-29 01:08, Cristian Rodríguez wrote:

...

A native systemd unit is available here:

http://pkgs.fedoraproject.org/cgit/gpm.git/tree/gpm.service

We need to add it to our packages...

copy it to /etc/systemd/system , then issue systemctl --system daemon-reload , systemctl enable gpm.service , systemctl restart gpm.service

So, with systemD the administrator has lost the power to choose the runleves a service runs?

For all that they keep saying "there is no such thing as runlevels any more" there are a close equivalent, they are just called something else, but they define desired sets of services. They just call them "targets" instead of "runlevels". You may think of both targets and runlevels as "profiles". For all systemds problems, that's not one. You can define an infinite number of targets vs just a few runlevels. I don't personally have any need for more than a few "profiles" (off, on, single-user, single-user-network, multi-user-network-quiescent-root-only) but I'm all for arbitrary flexibility for it's own sake. If infinite profiles are possible, maybe someone somewhere would discover a killer use for that possibility. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 28/09/12 05:13, eddie escribió:

...

Is chkconfig now obselete?

Yes.

I'm sure we'd have a lot less of those endless discussions if you'd sometimes just refrain from commenting. Not only is using chkconfig less clumsy than those native systemctl commands, systemd itself in fact relies on chkconfig for sysv compat. So no, it's not obsolete at all. The interaction of systemd with chkconfig and vice versa chkconfig with systemd need some polishing though. Patches welcome. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org