[sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing
urs.frey at post.ch
urs.frey at post.ch
Mon Sep 8 06:19:37 MDT 2014
Hello Mark
Ok I had a closer look at # man systemctl
When issuing # systemctl list-unit-files all system unit-files are listed with their capability
v03er9:~ # systemctl list-unit-files | grep systemd
systemd-ask-password-console.path static
systemd-ask-password-plymouth.path static
systemd-ask-password-wall.path static
systemd-ask-password-console.service static
systemd-ask-password-plymouth.service static
systemd-ask-password-wall.service static
systemd-backlight at .service static
systemd-binfmt.service static
systemd-fsck-root.service static
systemd-fsck at .service static
systemd-halt.service static
systemd-hibernate.service static
systemd-hostnamed.service static
systemd-hybrid-sleep.service static
systemd-initctl.service static
systemd-journal-flush.service static
systemd-journald.service static
systemd-kexec.service static
systemd-localed.service static
systemd-logind.service static
systemd-machined.service static
systemd-modules-load.service static
systemd-nspawn at .service disabled
systemd-poweroff.service static
systemd-quotacheck.service static
systemd-random-seed.service static
systemd-readahead-collect.service enabled
systemd-readahead-done.service static
systemd-readahead-drop.service enabled
systemd-readahead-replay.service enabled
systemd-reboot.service static
systemd-remount-fs.service static
systemd-rfkill at .service static
systemd-shutdownd.service static
systemd-suspend.service static
systemd-sysctl.service static
systemd-timedated.service static
systemd-tmpfiles-clean.service static
systemd-tmpfiles-setup-dev.service static
systemd-tmpfiles-setup.service static
systemd-udev-root-symlink.service static
systemd-udev-settle.service static
systemd-udev-trigger.service static
systemd-udevd.service static
systemd-update-utmp-runlevel.service static
systemd-update-utmp.service static
systemd-user-sessions.service static
systemd-vconsole-setup.service static
systemd-initctl.socket static
systemd-journald.socket static
systemd-shutdownd.socket static
systemd-udevd-control.socket static
systemd-udevd-kernel.socket static
systemd-readahead-done.timer static
systemd-tmpfiles-clean.timer static
v03er9:~ #
And from # man systemctl I found this
is-enabled NAME...
Checks whether any of the specified unit files are enabled (as with enable). Returns an exit code of 0 if at
least one is enabled, non-zero otherwise. Prints the current enable status (see table). To suppress this
output, use --quiet.
Table 1. is-enabled output
+------------------------------------------------------------------+
│Printed string │ Meaning │ Return value │
+------------------------------------------------------------------+
│"enabled" │ Enabled through a symlink in │ │
+------------------+ .wants directory (permanently │ 0 │
│"enabled-runtime" │ or just in /run) │ │
+------------------------------------------------------------------+
│"linked" │ Made available through a │ │
+------------------+ symlink to the unit file │ 1 │
│"linked-runtime" │ (permanently or just in /run) │ │
+------------------------------------------------------------------+
│"masked" │ Disabled entirely (permanently │ │
+------------------+ or just in /run) │ 1 │
│"masked-runtime" │ │ │
+------------------------------------------------------------------+
│"static" │ Unit is not enabled, but has │ 0 │
│ │ no provisions for enabling in │ │
│ │ [Install] section │ │
+------------------------------------------------------------------+
│"disabled" │ Unit is not enabled │ 1 │
+------------------------------------------------------------------+
So your statement
> There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :(
can be put into context when using “# systemctl list-unit-files | grep static
And all these “static” service files belong to the very base of the systemD environment.
This is the context I was looking for
Thanks
Best regards
Urs Frey
Post CH AG
Informationstechnologie
IT Betrieb
Webergutstrasse 12
3030 Bern (Zollikofen)
Telefon : ++41 (0)58 338 58 70
FAX : ++41 (0)58 667 30 07
E-Mail: urs.frey at post.ch
-----Ursprüngliche Nachricht-----
Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Mark Post
Gesendet: Friday, September 05, 2014 6:57 PM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing
>>> On 8/27/2014 at 04:38 AM, <urs.frey at post.ch<mailto:urs.frey at post.ch>> wrote:
> Aug 27 08:13:59 h05cnh systemd[1]: Started Login Service.
> Aug 27 08:13:59 h05cnh systemd-logind[10059]: New seat seat0.
> Aug 27 08:13:59 h05cnh systemd-logind[10059]: Watching system buttons on
> /dev/input/event2 (Power Button)
> + systemctl disable systemd-logind
> + systemctl stop systemd-logind
> +sleep 300
> + systemctl enable systemd-logind
> The unit files have no [Install] section. They are not meant to be enabled
> using systemctl.
> Possible reasons for having this kind of units are:
> 1) A unit may be statically enabled by being symlinked from another unit's
> .wants/ or .requires/ directory.
> 2) A unit's purpose may be to act as a helper for some other unit which has
> a requirement dependency on it.
> 3) A unit may be started when needed via activation (socket, path, timer,
> D-Bus, udev, scripted systemctl call, ...).
There is a class of service files that are called "static." They cannot be enabled or disabled, per se. It would be nice if systemctl disable would tell you that. :(
You _can_ mask/unmask them, however. So, try this:
systemctl mask systemd-logind.service
systemctl stop systemd-logind.service
systemctl unmask systemd-logind.service
systemctl start systemd-logind.service
Mark Post
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com<mailto:sles-beta at lists.suse.com>
http://lists.suse.com/mailman/listinfo/sles-beta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140908/ab494998/attachment.htm>
More information about the sles-beta
mailing list