Le 28/11/2017 à 22:46, Dave Howorth a écrit :

i.e why the difference in the target between starting and stopping?

you start and stop a service and reach a target... jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 28 Nov 2017 17:32:58 -0500 Felix Miata wrote:

Dave Howorth composed on 2017-11-28 21:46 (UTC):

...

On Tue, 28 Nov 2017 13:28:34 -0500 Felix Miata wrote:

...

...

Richmond composed on 2017-11-28 18:22 (UTC):

...

Ricmond doesn't seem to be having much luck with his question. I can't answer it myself but I can see some difficulties with the proposed answers:

...

...

...

If I can start X with:

...

...

...

systemctl start graphical.target

...

...

...

should I not also be able to stop it again with:

...

...

...

systemctl stop graphical.target ?

...

...

...

I have found this leaves the system unusable with no virtual console or graphical interface, so I have to reboot.

...

...

As it was with runlevels, where one ended X with 'init 3' or 'telinit 3', in systemd one switches the "target", thus: 'systemctl isolate multi-user.target'. 'init 3' is said to be an alias to 'systemctl isolate multi-user.target', and to switch back to X, 'systemctl isolate graphical.target', or 'init 5'.

...

If 'stopping' is done by 'systemctl isolate multi-user.target', why is 'starting' done by 'systemctl isolate graphical.target'?

...

i.e why the difference in the target between starting and stopping?

Because it's systemd we're dealing with, not sysvinit. Systemd "runlevel" switching requires adopting some *other* target (via isolate), and deactivation of all incompatible targets. Having no target active (isolated?) is not allowed. In systemd language, isolate approximately equates to start some "target" plus stop other target.

Thanks for the explanation, Felix. I'm still curious why systemctl start graphical.target works then? Personally, I'm with carlos, if he's correct. Just remember init 3 and init 5! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth composed on 2017-11-28 22:51 (UTC):

I'm still curious why systemctl start graphical.target works then? Have you tried it yourself? I haven't. My guess is that it might work only if a "lower level" target was current, such as multi-user.

Personally, I'm with carlos, if he's correct. Just remember init 3 and init 5!

AFAICT, neither init nor telinit is technically an alias: # which telinit /sbin/telinit # which init /sbin/init # ls -gG /sbin/*init lrwxrwxrwx 1 26 Sep 6 03:29 /sbin/init -> ../usr/lib/systemd/systemd lrwxrwxrwx 1 18 Sep 6 03:29 /sbin/telinit -> /usr/bin/systemctl # ls -gG /usr/bin/systemctl /usr/lib/systemd/systemd -rwxr-xr-x 1 696304 Sep 3 06:23 /usr/bin/systemctl -rwxr-xr-x 1 1589144 Sep 3 06:23 /usr/lib/systemd/systemd https://www.freedesktop.org/software/systemd/man/systemd.html says: "...init and telinit are mostly equivalent when invoked from normal login sessions." I've had problems with incomplete switching via the *init systemd aliases, so most often I boot to multi-user and run startx, thus avoiding all the above. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

I am seeing some problems with these runlevels. Firstly, if I go from multi-user to graphical, and then back to multi-user, I lose my wifi, even though wifi works at first in multi-user because it is controlled through Yast/wicked. Secondly I have an intermittent problem with the system being locked up when I go from graphical to multi-user. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote:

* Richmond [12-01-17 10:15]:

...

I am seeing some problems with these runlevels.

Firstly, if I go from multi-user to graphical, and then back to multi-user, I lose my wifi, even though wifi works at first in multi-user because it is controlled through Yast/wicked. I find the same, only not on all machines. fwiw, I stack commands, adding "systemctl restart wicked wickedd network" to the end of changing runlevels on boxes where it is a problem. That has solved one problem, that "ifup wlan0" doesn't start wifi, but "systemclt restart wickedd" does.

...

Secondly I have an intermittent problem with the system being locked up when I go from graphical to multi-user. cannot help here, have not experienced that.

ps: all my machines used to loose network connection when changing "runlevels", including wired. but it has improved.

I notice in Yast services manager that wickedd is disabled for multi-user. If I enable it, it gets changed back to disabled the next time I go into Yast services manager. :/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

* Patrick Shanahan [12-01-17 15:10]:

* Richmond [12-01-17 15:04]:

...

Patrick Shanahan wrote:

...

* Richmond [12-01-17 10:15]:

...

I am seeing some problems with these runlevels.

Firstly, if I go from multi-user to graphical, and then back to multi-user, I lose my wifi, even though wifi works at first in multi-user because it is controlled through Yast/wicked. I find the same, only not on all machines. fwiw, I stack commands, adding "systemctl restart wicked wickedd network" to the end of changing runlevels on boxes where it is a problem. That has solved one problem, that "ifup wlan0" doesn't start wifi, but "systemclt restart wickedd" does.

yes, sometime ifup leaves with msg "updating". make sure your wifi is wlan0, I have several like wlp7s0

...

...

...

Secondly I have an intermittent problem with the system being locked up when I go from graphical to multi-user. cannot help here, have not experienced that.

ps: all my machines used to loose network connection when changing "runlevels", including wired. but it has improved.

I notice in Yast services manager that wickedd is disabled for multi-user. If I enable it, it gets changed back to disabled the next time I go into Yast services manager. :/

never noticed that, will look

for multi-user I see the same disabled wickedd on my wireless machines, but it is enabled on the wired boxes. I know not why???? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Felix Miata wrote:

Richmond composed on 2017-11-28 18:22 (UTC):

...

If I can start X with: systemctl start graphical.target should I not also be able to stop it again with: systemctl stop graphical.target ? I have found this leaves the system unusable with no virtual console or graphical interface, so I have to reboot. As it was with runlevels, where one ended X with 'init 3' or 'telinit 3', in systemd one switches the "target", thus: 'systemctl isolate multi-user.target'. 'init 3' is said to be an alias to 'systemctl isolate multi-user.target', and to switch back to X, 'systemctl isolate graphical.target', or 'init 5'.

'systemctl isolate multi-user.target' had the same effect, all I could do was press the off button to shut the system down. However, I find that telinit 3, and telinit 5, do work as expected. There must be something else at work here... -- 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 Tuesday, 2017-11-28 at 22:10 -0000, Richmond wrote:

Felix Miata wrote:

...

Richmond composed on 2017-11-28 18:22 (UTC):

...

If I can start X with: systemctl start graphical.target should I not also be able to stop it again with: systemctl stop graphical.target ? I have found this leaves the system unusable with no virtual console or graphical interface, so I have to reboot. As it was with runlevels, where one ended X with 'init 3' or 'telinit 3', in systemd one switches the "target", thus: 'systemctl isolate multi-user.target'. 'init 3' is said to be an alias to 'systemctl isolate multi-user.target', and to switch back to X, 'systemctl isolate graphical.target', or 'init 5'.

systemctl isolate graphical.target systemctl isolate multi-user.target

These commands seem to be working now too. Something must have got messed up before, maybe by my use of start graphical.target.

It maybe easier to remember the traditional "init 5" and "init 3". They are supposed to be supported for ever in systemd. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlod4DwACgkQtTMYHG2NR9VWZwCeJuV5pgC+DRKnfGiGZLXGeK7R WakAoIynk96yDgF6BzLgmLQshvfrMqU4 =e+pP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 28 Nov 2017 21:39:56 +0300 Andrei Borzenkov wrote:

28.11.2017 21:22, Richmond пишет:

Richmond doesn't seem to be having much luck with his question. I can't answer it myself but I can see some difficulties with the proposed answers:

...

If I can start X with:

systemctl start graphical.target

should I not also be able to stop it again with:

systemctl stop graphical.target ?

If "it" in above sentence refers to "X" - no, you should not.

It would be more helpful if you explained WHY the symmetry does not apply.

...

I have found this leaves the system unusable with no virtual console or graphical interface, so I have to reboot.

I cannot reproduce it on either Leap or TW.

And to quote your implied question - what is 'it' here? -- 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 Wednesday, 2017-11-29 at 08:56 +0100, Mathias Homann wrote:

Hi,

"systemctl start" starts a target or service

"systemctl stop" stops a target or service

"systemctl isolate" only works with targets that CAN be isolated, i.e. that are something akin to a runlevel. The four major ones emergency.target, rescue.target, multi-user.target and graphical.target are such targets, and therefor should be reached by isolating them, not just starting them.

What "isolate" does is comparable to switching runlevels. It checks the dependecies of the given target, and STOPS everything that is not needed anymore, and STARTS everything that is needed but not running.

Hope that helps a bit.

Thank you, yes :-) - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloeu40ACgkQtTMYHG2NR9VGCACdGq+79y8r95/4Wn1ZQWkmJGMH uHoAn2rR+dKgiilCFzatC8wATOHnGRHf =LilX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org