agetty --reload

agetty --reload

[Sitsofe Wheeler]

Hi,

I've been trying to use agetty --reload from util-linux 2.26 but I've
been running into problems.

The main issue seems to be that /etc/issue isn't reparsed when agetty
--reload is done unless /run/agetty.reload exists before the original
agetty is started. Is this the intended behaviour?

The second issue occurs when --autologin and --login-pause are being
used and a reload happens even when the above is done. Since the login
program hasn't actually been started (as we are waiting for the user
to press enter) I expected the reload to cause agetty to reload
/etc/issue and start waiting again but this does not currently happen.
Is this also intentional?

-- 
Sitsofe | http://sucs.org/~sits/

Re: agetty --reload

[Karel Zak]

On Sun, Mar 08, 2015 at 09:02:11PM +0000, Sitsofe Wheeler wrote:
> The main issue seems to be that /etc/issue isn't reparsed when agetty
> --reload is done unless /run/agetty.reload exists before the original
> agetty is started. Is this the intended behaviour?

No, this is a bug, fixed by commit c9f5ec0faa2b2d9cf7fc162baf99499457b8b909.

> The second issue occurs when --autologin and --login-pause are being
> used and a reload happens even when the above is done. Since the login
> program hasn't actually been started (as we are waiting for the user
> to press enter) I expected the reload to cause agetty to reload
> /etc/issue and start waiting again but this does not currently happen.
> Is this also intentional?

Well, it wasn't implemented, improved by commit c2ef308bbfdc9fb9a0053e258828f5bd6fbb0c5d.

The changes will be in v2.26.1.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: agetty --reload

[Sitsofe Wheeler]

On 9 March 2015 at 11:52, Karel Zak <kzak@redhat.com> wrote:
> On Sun, Mar 08, 2015 at 09:02:11PM +0000, Sitsofe Wheeler wrote:
>> The main issue seems to be that /etc/issue isn't reparsed when agetty
>> --reload is done unless /run/agetty.reload exists before the original
>> agetty is started. Is this the intended behaviour?
>
> No, this is a bug, fixed by commit c9f5ec0faa2b2d9cf7fc162baf99499457b8b909.
>
>> The second issue occurs when --autologin and --login-pause are being
>> used and a reload happens even when the above is done. Since the login
>> program hasn't actually been started (as we are waiting for the user
>> to press enter) I expected the reload to cause agetty to reload
>> /etc/issue and start waiting again but this does not currently happen.
>> Is this also intentional?
>
> Well, it wasn't implemented, improved by commit c2ef308bbfdc9fb9a0053e258828f5bd6fbb0c5d.
>
> The changes will be in v2.26.1.

Phew, that was fast! I've found with your patches the first issue is
fixed but when waiting at the [press ENTER to login] prompt agetty
--reload still has no effect...

-- 
Sitsofe | http://sucs.org/~sits/

Re: agetty --reload

[Karel Zak]

On Mon, Mar 09, 2015 at 02:38:23PM +0000, Sitsofe Wheeler wrote:
> On 9 March 2015 at 11:52, Karel Zak <kzak@redhat.com> wrote:
> > On Sun, Mar 08, 2015 at 09:02:11PM +0000, Sitsofe Wheeler wrote:
> >> The main issue seems to be that /etc/issue isn't reparsed when agetty
> >> --reload is done unless /run/agetty.reload exists before the original
> >> agetty is started. Is this the intended behaviour?
> >
> > No, this is a bug, fixed by commit c9f5ec0faa2b2d9cf7fc162baf99499457b8b909.
> >
> >> The second issue occurs when --autologin and --login-pause are being
> >> used and a reload happens even when the above is done. Since the login
> >> program hasn't actually been started (as we are waiting for the user
> >> to press enter) I expected the reload to cause agetty to reload
> >> /etc/issue and start waiting again but this does not currently happen.
> >> Is this also intentional?
> >
> > Well, it wasn't implemented, improved by commit c2ef308bbfdc9fb9a0053e258828f5bd6fbb0c5d.
> >
> > The changes will be in v2.26.1.
> 
> Phew, that was fast! I've found with your patches the first issue is
> fixed but when waiting at the [press ENTER to login] prompt agetty
> --reload still has no effect...

 It works for me.

 # grep autologin /etc/systemd/system/getty@.service 
 ExecStart=-/sbin/agetty --autologin kzak --login-pause --noclear %I $TERM

 # echo "Hello world!" >> /etc/issue
 # agetty --reload

 .. then I see the "Hello..." line before [press ENTER to login].

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: agetty --reload

[Sitsofe Wheeler]

On 9 March 2015 at 20:12, Karel Zak <kzak@redhat.com> wrote:
> On Mon, Mar 09, 2015 at 02:38:23PM +0000, Sitsofe Wheeler wrote:
>>
>> Phew, that was fast! I've found with your patches the first issue is
>> fixed but when waiting at the [press ENTER to login] prompt agetty
>> --reload still has no effect...
>
>  It works for me.
>
>  # grep autologin /etc/systemd/system/getty@.service
>  ExecStart=-/sbin/agetty --autologin kzak --login-pause --noclear %I $TERM
>
>  # echo "Hello world!" >> /etc/issue
>  # agetty --reload
>
>  .. then I see the "Hello..." line before [press ENTER to login].

You're right - I was mistaken and it all works.

Just for the record, the reason I was testing this is because I wanted
agetty to update its display of /etc/issue whenever the networking
changed so IP addresses would be updated. My setup is using networkd
and I have the following systemd units:

/etc/systemd/system/multi-user.target.wants/systemd-networkd-change.path:
[Unit]
Description=Update getty on network changes
DefaultDependencies=no
Requisite=systemd-networkd.service
Before=systemd-networkd.service

[Path]
PathChanged=/run/systemd/netif/state

[Install]
WantedBy=multi-user.target

/etc/systemd/system/systemd-networkd-change.service:
[Unit]
Description=Update getty on network changes
DefaultDependencies=no
Conflicts=shutdown.target

[Service]
Type=oneshot
# sleep is needed if watching the state file because it changes too soon
ExecStartPre=/usr/bin/sleep 0.5s
ExecStart=/usr/local/sbin/agetty --reload

The only snag is that the display goes weird when the console is
blanked and an update happens but that could be a VMware bug.

-- 
Sitsofe | http://sucs.org/~sits/