[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
Wed Aug 27 02:38:37 MDT 2014
Hello Josef
I tried to modify /usr/lib/systemd/system/autoyast-initscripts.service and to set a Before= into the unit file
(I know from Frederic: NEVER-Ever do modify under /usr/lib...! but just to test and on the search for a method...)
h05cnh:/var/adm/autoinstall/logs # cat /usr/lib/systemd/system/autoyast-initscripts.service
[Unit]
Description=Autoyast2 Init Scripts
After=remote-fs.target network.target time-sync.target mail-transfer-agent.target hwscan.service ypbind.service YaST2-Second-Stage.service
Before=systemd-logind.service
[Service]
Type=oneshot
Environment=TERM=linux
ExecStartPre=-/usr/bin/plymouth --hide-splash
ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh
RemainAfterExit=yes
TimeoutSec=0
[Install]
WantedBy=default.target
h05cnh:/var/adm/autoinstall/logs #
BUT with this method only, I get the console login Prompt all-the same long before the autoinst init-script has terminated.
========================
So I got the idea, to simply disable system-logind at the begin of my autoinst init-script and re-enable at the end of my autoinst init-script
It is easy to reproduce with autoyast. I try to disable the console login prompt, the my init-script does wait for 5min and should re-enable and finally show the console prompt after terminating my init-script.
<init-scripts config:type="list">
<script>
<filename>init-script.sh</filename>
<interpreter>shell</interpreter>
<location></location>
<source><![CDATA[#!/bin/sh
logdir=/var/adm/autoinstall/logs
logf=${logdir}/init-script.sh.log
#
# check systemd-login here
systemctl status systemd-logind
systemctl disable systemd-logind
systemctl stop systemd-logind
#
Sleep 300
#
systemctl enable systemd-logind
systemctl start systemd-logind
systemctl status systemd-logind
#
]]></source>
</script>
</init-scripts>
</scripts>
<partitioning config:type="list">
=================================
Unfortunately I got these error messages in my init-script.sh.log Logfile
h05cnh:/var/adm/autoinstall/logs # cat init-script.sh.log
+ logdir=/var/adm/autoinstall/logs
+ logf=/var/adm/autoinstall/logs/init-script.sh.log
+ systemctl status systemd-logind
systemd-logind.service - Login Service
Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
Active: active (running) since Wed 2014-08-27 08:13:59 CEST; 2h 0min ago
Docs: man:systemd-logind.service(8)
man:logind.conf(5)
http://www.freedesktop.org/wiki/Software/systemd/logind
http://www.freedesktop.org/wiki/Software/systemd/multiseat
Main PID: 10059 (systemd-logind)
Status: "Processing requests..."
CGroup: /system.slice/systemd-logind.service
└─10059 /usr/lib/systemd/systemd-logind
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, ...).
+ systemctl start systemd-logind
Job for systemd-logind.service canceled.
+ systemctl status systemd-logind
h05cnh:/var/adm/autoinstall/logs #
And I got the root console login prompt anyway, even though syewstemd-logind was dead (with systemctl status system-logind)
So from my point of view the proper function of autoinst init-script is not given.
This is really a bad situation.
So I really need to run autoinst init-script without the possibility of already open root console login
The problem is, that when trying to install software using zypper within autoinst post-script phase, zypper is locked by y2base process and zypper is not available
Error: Could not update: Execution of '/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm pst-rubygem-stomp' returned 7:
System management is locked by the application with pid 4778 (y2base).
Close this application before trying again.
Wrapped exception:
Execution of '/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm pst-rubygem-stomp' returned 7: System management is locked by the application with pid 4778 (y2base).
Close this application before trying again.
Error: /Stage[main]/Admin::Mcollective/Package[pst-rubygem-stomp]/ensure: change from absent to latest failed: Could not update: Execution of '
/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm pst-rubygem-stomp' returned 7: System management is locked by the application with pid 4778 (y2base).
Close this application before trying again.
So within the autoyast process:
post-script: zypper not usable because of being locked by y2base
init-script: zypper usable, bat login already open, leading to early logins by inpatient installing operators.
From my point of view the autoyast process itself has to be carefully reviewed in the context of systemD.
It has become unusable now
Maybe you have some ideas ??
Thank you very much for your feedback
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: Josef Reidinger [mailto:jreidinger at suse.cz]
Gesendet: Tuesday, August 26, 2014 3:57 PM
An: Frey Urs, IT222
Cc: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing
Hi Urs,
you can modify autoyast-initscripts.service itself if you add in Unit
"Before" part with required service which is in your case
systemd-logind.service [1]. Question is if we can do it for everyone and
change default.
Josef
[1]
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=
On Tue, 26 Aug 2014 13:51:04 +0000
<urs.frey at post.ch> wrote:
> Hello Josef
>
> I do not understand what you exactly mean
> I need to run / free user login after successful termination of
> autoinst init-script But as far as I understand the unit file, the
> initscript runs after the listed services below
>
> h05cni:~ # cat /usr/lib/systemd/system/autoyast-initscripts.service
> [Unit]
> Description=Autoyast2 Init Scripts
> After=remote-fs.target network.target time-sync.target
> mail-transfer-agent.target hwscan.service ypbind.service
> YaST2-Second-Stage.service
>
> [Service]
> Type=oneshot
> Environment=TERM=linux
> ExecStartPre=-/usr/bin/plymouth --hide-splash
> ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh
> RemainAfterExit=yes
> TimeoutSec=0
>
> [Install]
> WantedBy=default.target
>
> h05cni:~ #
>
> So I guess, this one here should be modified to run after init-script
> during installation using autoyast
>
> h05cni:~ # cat /usr/lib/systemd/system/systemd-logind.service
> # This file is part of systemd.
> #
> # systemd is free software; you can redistribute it and/or modify it
> # under the terms of the GNU Lesser General Public License as
> published by # the Free Software Foundation; either version 2.1 of
> the License, or # (at your option) any later version.
>
> [Unit]
> Description=Login Service
> Documentation=man:systemd-logind.service(8) man:logind.conf(5)
> Documentation=http://www.freedesktop.org/wiki/Software/systemd/logind
> Documentation=http://www.freedesktop.org/wiki/Software/systemd/multiseat
> Wants=user.slice
> After=nss-user-lookup.target user.slice
>
> # Ask for the dbus socket. If running over kdbus, the socket will
> # not be actually used.
> Wants=dbus.socket
> After=dbus.socket
>
> [Service]
> ExecStart=/usr/lib/systemd/systemd-logind
> Restart=always
> RestartSec=0
> BusName=org.freedesktop.login1
> CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN
> CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER
> CAP_SYS_TTY_CONFIG WatchdogSec=1min
>
> # Increase the default a bit in order to allow many simultaneous
> # logins since we keep one fd open per session.
> LimitNOFILE=16384
> h05cni:~ #
>
> 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 Josef
> Reidinger Gesendet: Tuesday, August 26, 2014 3:37 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 Tue, 26 Aug 2014 15:31:45 +0200
> "Thorsten Kukuk" <kukuk at suse.de> wrote:
>
> >
> > Hi,
> >
> > On Tue, Aug 26, urs.frey at post.ch wrote:
> >
> > > Hi
> > >
> > > When trying to install SLES12 Rc2 x86_64 using autoyast with
> > > init-scripts within autoinst.xml the installation process does not
> > > wait until init-script has terminated. So I can already see the
> > > final login screen even though my init-script within autoinst.xml
> > > is still running
> >
> > Yes, that's the new world of systemd: start every service as early
> > as possible in parallel.
> >
> > > I consider this as bug.
> > > Please fix this within autoyast
> >
> > I'm not sure if there is anything autoyast can do here.
>
> Well, autoyast can add login to list of services that should be run
> after its init script here
> https://github.com/yast/yast-autoinstallation/blob/master/scripts/autoyast-initscripts.service#L3
> Currently it lists only some specific stuff, that can be ignored on
> target device. So it is possible if it is consider as requested
> behavior to run scripts before login prompt.
>
> Josef
>
> >
> > Thorsten
> >
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>
More information about the sles-beta
mailing list