[opensuse] yast service manager enable active
Hello :-) I wonder what is *exactly* the meaning of active/inactive and enable/disable in yast service manager I ask this because some services are disabled, but active. just after boot (for example apparmor). I could understand an enabled service that do not start, but a disabled service should never be started what do I miss? thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/05/14 05:18, jdd escribió:
Hello :-)
I wonder what is *exactly* the meaning of active/inactive and enable/disable in yast service manager
I ask this because some services are disabled, but active. just after boot (for example apparmor).
I could understand an enabled service that do not start, but a disabled service should never be started
what do I miss?
thanks jdd
I do not know if the service module has been really fixed to make sense with systemd. There are various possible states - Enabled + active - disabled + active - Enabled + inactive - disabled + inactive - masked (this is the only state where the service won't start ever) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 11/05/2014 17:06, Cristian Rodríguez a écrit :
I do not know if the service module has been really fixed to make sense with systemd.
ok
There are various possible states
- Enabled + active - disabled + active - Enabled + inactive - disabled + inactive - masked (this is the only state where the service won't start ever)
well, what does that mean? may be what is explained here: http://www.freedesktop.org/software/systemd/man/systemctl.html this sentence is confusing: "Depending on whether --system, --user, --runtime, or --global is specified, this enables the unit for the system, for the calling user only, for only this boot of the system, or for all future logins of all users, or only this boot." --system is for the system, ok --user is for the calling user, ok --runtime is only for this boot (or just for the present running time, no boot necessary) ? --global is for all future logging of all users but what is the end of the sentence "or only this boot."? all boots or only this boot? say if I'm right: for the setup of a server the important part is the "enable/disable" part? this allow a service to start on boot, providing it's correctly configured? The "active/inactive" part may ignored or only considered informative - making tests I could enter an infinite loop that asked for a hard reboot of my server :-( I understand this mechanism is a dependency system between various services. thanks -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 11/05/14 11:57, jdd escribió:
"Depending on whether --system, --user, --runtime, or --global is specified, this enables the unit for the system, for the calling user only, for only this boot of the system, or for all future logins of all users, or only this boot."
--system is for the system, ok --user is for the calling user, ok --runtime is only for this boot (or just for the present running time, no boot necessary) ? --global is for all future logging of all users
but what is the end of the sentence "or only this boot."? all boots or only this boot?
"runtime" .. this particular service is only active for the time the machine is running (will go away after reboot) as the information necessary to keep the service running is written to /run. this allow a service to start on boot, providing
it's correctly configured?
There are services that: - Start at boot unconditionally,some of them can be disabled some cannot or should not. - Start only when the system administrator enables them - Start only when there is a particular $other event, namely, another service is available, hardware, user logged, a particular time of the day is omes, a timer expires..or a combination of all of those, things can get pretty complex. - A service cannot start only if it is masked. -- Cristian "I don't know the key to success, but the key to failure is trying to please everybody." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-11 17:57, jdd wrote:
There are various possible states
- Enabled + active - disabled + active - Enabled + inactive - disabled + inactive - masked (this is the only state where the service won't start ever)
well, what does that mean?
I think that "active" means that it is running now. "Enabled" means that it is set to automatically start (at boot? When needed? Both?) More or less. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNvo/0ACgkQja8UbcUWM1zdCgD+J0mrznqwcwGUdDel39uu+Zpk A4r96Tu6V3wEkT0SkVAA/A45rKdf3mqoTzDPya5QWDAyYsPLEbPYNuSZUtv/PZDV =AlhQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 11/05/2014 18:23, Carlos E. R. a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-11 17:57, jdd wrote:
well, what does that mean?
I think that "active" means that it is running now. "Enabled" means that it is set to automatically start (at boot? When needed? Both?)
More or less.
yes, that's what this used to mean, but see the other posts, it's now a bit more complicated. once when you "disabled" a service (in YaST), it was immediately stopped. Now it's not, or not always jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-11 18:28, jdd wrote:
Le 11/05/2014 18:23, Carlos E. R. a écrit :
yes, that's what this used to mean, but see the other posts, it's now a bit more complicated.
once when you "disabled" a service (in YaST), it was immediately stopped. Now it's not, or not always
Well, sometimes when you disabled a service it was also stopped, and now it doesn't. But it is not YaST, I see it with systemctl, so perhaps they changed the defaults. You can manually start or stop a service, and it remains disabled, it will not be automatically started on next boot, for instance. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNvwGUACgkQja8UbcUWM1z4rwD/ezz2mVQnj5l8jv2o8Xm9fZn/ wUwH2aRK/z9dtUaeIRYA/1MbX9dxADp0DJa4/ICEwSRaCAiPC02h7+Agqlm15ZEz =ybQ2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
В Sun, 11 May 2014 18:23:25 +0200
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-11 17:57, jdd wrote:
There are various possible states
- Enabled + active - disabled + active - Enabled + inactive - disabled + inactive - masked (this is the only state where the service won't start ever)
well, what does that mean?
I think that "active" means that it is running now. "Enabled" means that it is set to automatically start (at boot? When needed? Both?)
No. "enabled" means that links that are specified in [Install] section of service definition are created. Nothing more. It does not even imply that service will ever be started. If foo.service has [Install] WantedBy=service-that-is-never-started.service then "systemctl enable" will create link /etc/systemd/system/service-that-is-never-started.service.wants/foo.service but that's it. Unless foo.service is started by some other means, it will not run. The main confusion stems from the fact that as opposed to sysvinit, there is no single state (run level) to enable service in, but most people subconsciously expect it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlN5fbIACgkQR6LMutpd94x44ACfd4kPBWda0wKVx2gVQwRakDPS kwkAnR91hG/DkM/5IpcUopXFEloNj+jF =T8Hd -----END PGP SIGNATURE----- N▀╖╡ФЛr╦⌡yИ ┼Z)z{.╠О╝·к⌡╠йБmЙ)z{.╠Й+│:╒{Zrшaz▄'z╥╕j)h╔ИЛ╨г╬ё ч╝┼^·к╛z┼Ю
Le 19/05/2014 05:42, Andrey Borzenkov a écrit :
but that's it. Unless foo.service is started by some other means, it will not run.
well, how to make sure it's started at boot then? thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-19 07:36, jdd wrote:
Le 19/05/2014 05:42, Andrey Borzenkov a écrit :
but that's it. Unless foo.service is started by some other means, it will not run.
well, how to make sure it's started at boot then?
You can not. For instance, people are having problems with cups not starting, they have to start it manually. Supposedly it should start automatically, either at boot, or by socket request, but it does not, or not for everybody. So, some remove the socket activation, and this appears to work, but again, not for everybody. There was a mandatory update that should have solved this, but again, not for everybody. Some people say that the recent cups package in the cups repo works better, but again... Some simply put a start up job in cron and get done with... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN5068ACgkQja8UbcUWM1xvXgEAnaKdjEzZ5vC11wGORpmk5e8u FILvdbqLP20UIcwUmMkA/A+KCamdunChVjPOsL8yUdrIrPcNW9I2L8y1848OtOv6 =ErsO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 19/05/2014 11:49, Carlos E. R. a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-19 07:36, jdd wrote:
well, how to make sure it's started at boot then?
You can not.
well, if the network do not start on my histed server, It's a real problem :-)
For instance, people are having problems with cups not starting,
but it seems to be a bug, that's not avoidable sometime
Some simply put a start up job in cron and get done with...
not even a boot script with systemctl restart network.service? thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-19 12:28, jdd wrote:
Le 19/05/2014 11:49, Carlos E. R. a écrit :
Some simply put a start up job in cron and get done with...
not even a boot script with systemctl restart network.service?
Maybe. The problem sometimes is how early or late the script runs. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN54L0ACgkQja8UbcUWM1y1KQEAjSPi13AwoM4gE8yPmcKzz93S g5GyZerOX9yNOOJSpMYA/368QxrhWbAx4zRF/z+X9q9BqpnxDlYQ2jHpd1OjGqc8 =7WE0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 19 May 2014 07:36:39 +0200
jdd
Le 19/05/2014 05:42, Andrey Borzenkov a écrit :
but that's it. Unless foo.service is started by some other means, it will not run.
well, how to make sure it's started at boot then?
The obvious answer - do not make it to be WnatedBy something, that is never started itself :) You can make it WantedBy multi-user.target or graphical.target. These are the most close translation of run level 3 and 5 in systemd. Usually one of them is also set as default target (cf. default run-level in sysvinit) and graphical.target also makes sure multi-user.target is started first. Then "enabled" will mean what you expect - something that is started at boot time. It is still possible to boot system bypassing default targets, but that is nothing new and is not different from sysvinit. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 19/05/2014 17:53, Andrey Borzenkov a écrit :
В Mon, 19 May 2014 07:36:39 +0200 jdd
пишет: Le 19/05/2014 05:42, Andrey Borzenkov a écrit :
but that's it. Unless foo.service is started by some other means, it will not run.
well, how to make sure it's started at boot then?
The obvious answer - do not make it to be WnatedBy something, that is never started itself :)
You can make it WantedBy multi-user.target or graphical.target. These are the most close translation of run level 3 and 5 in systemd. Usually one of them is also set as default target (cf. default run-level in sysvinit) and graphical.target also makes sure multi-user.target is started first. Then "enabled" will mean what you expect - something that is started at boot time.
It is still possible to boot system bypassing default targets, but that is nothing new and is not different from sysvinit.
ok, but do I need to write myself a config file or is there a command line to do so (systemctl...) thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Mon, 19 May 2014 18:13:08 +0200
jdd
Le 19/05/2014 17:53, Andrey Borzenkov a écrit :
В Mon, 19 May 2014 07:36:39 +0200 jdd
пишет: Le 19/05/2014 05:42, Andrey Borzenkov a écrit :
but that's it. Unless foo.service is started by some other means, it will not run.
well, how to make sure it's started at boot then?
The obvious answer - do not make it to be WnatedBy something, that is never started itself :)
You can make it WantedBy multi-user.target or graphical.target. These are the most close translation of run level 3 and 5 in systemd. Usually one of them is also set as default target (cf. default run-level in sysvinit) and graphical.target also makes sure multi-user.target is started first. Then "enabled" will mean what you expect - something that is started at boot time.
It is still possible to boot system bypassing default targets, but that is nothing new and is not different from sysvinit.
ok, but do I need to write myself a config file or is there a command line to do so (systemctl...)
I'm not sure I understand what you are asking. Of course you need to write service definition file if you want to create new service. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 19/05/2014 18:20, Andrey Borzenkov a écrit :
I'm not sure I understand what you are asking. Of course you need to write service definition file if you want to create new service.
no. If I want postfix to start at each reboot, what do I have to do after a fresh install? thanks jdd -- http://www.dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-19 22:54, jdd wrote:
Le 19/05/2014 18:20, Andrey Borzenkov a écrit :
I'm not sure I understand what you are asking. Of course you need to write service definition file if you want to create new service.
no. If I want postfix to start at each reboot, what do I have to do after a fresh install?
In theory, enabling should be enough. In my desktop, with ifup, it works. In this laptop, with network manager, it doesn't, because it apparently tries before network is up, and I always have to start it manually - which I notice when I try to send an email and fails. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN6fOMACgkQja8UbcUWM1xqNAD/RM/RJVpQsrNl+lTqk2voTcf7 4gFV21ZG7CSh424WArgA/jMsTiqitJQl+mph2wawRY1CVm3NTUfrXd+rQKhskjEf =EcE0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
В Mon, 19 May 2014 23:51:31 +0200
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-05-19 22:54, jdd wrote:
Le 19/05/2014 18:20, Andrey Borzenkov a écrit :
I'm not sure I understand what you are asking. Of course you need to write service definition file if you want to create new service.
no. If I want postfix to start at each reboot, what do I have to do after a fresh install?
In theory, enabling should be enough. In my desktop, with ifup, it works. In this laptop, with network manager, it doesn't, because it apparently tries before network is up, and I always have to start it manually - which I notice when I try to send an email and fails.
Yes, the main problem with NetworkManager is - when NetworkManager(.service) is started, it does not mean network is available. It can take quite a lot of time before NM finally brings up interfaces. So if you depend on it during boot, you should enable NetworkManager-wait-online.service and set suitable value for NM_ONLINE_TIMEOUT in /etc/syscofig/network/config. May be it should be made default. There was recent commit for upstream systemd which effectively does it for legacy sysvinit services. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlN6wpUACgkQR6LMutpd94zBjgCfeWEOMwa58eO4XuLxKagRWW6c CowAn3XjWHffHrWkJ66DuZExWlHceoj7 =veUm -----END PGP SIGNATURE----- N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-20 04:48, Andrey Borzenkov wrote:
В Mon, 19 May 2014 23:51:31 +0200 "Carlos E. R." <> пишет:
Yes, the main problem with NetworkManager is - when NetworkManager(.service) is started, it does not mean network is available. It can take quite a lot of time before NM finally brings up interfaces. So if you depend on it during boot, you should enable NetworkManager-wait-online.service and set suitable value for NM_ONLINE_TIMEOUT in /etc/syscofig/network/config.
May be it should be made default. There was recent commit for upstream systemd which effectively does it for legacy sysvinit services.
I'm unsure if that would delay the entire boot process. An alternative would be to have postfix start automatically on socket activation when something tries to send an email. Another to have it delay activation till network becomes available. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlN7IdkACgkQja8UbcUWM1wKWQEAgMT39ilAAonX8dASfx9vVIeL ZkMHLhKKBsv0F9wkJEkA/2uILhwBisSrEvKEoxVhEWJaX6OfI8/WsqSFz46Oz5Dd =n2k+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Andrey Borzenkov
-
Carlos E. R.
-
Carlos E. R.
-
Cristian Rodríguez
-
jdd