Andrei Borzenkov composed on 2024-05-25 08:34 (UTC+0300):

Felix Miata wrote:

...

I have multiple installations where I removed issue-generator for some period until I decided to reverse my attitude about it. The main idea was, and remains, I don't want to see IP addresses onscreen with VT logins. Now I have some installations where even though it has been reinstalled, login prompts on VTs are simply

...

hostname login:

...

on an otherwise blank screen until such time as I

...

systemctl start issue-generator.service

...

Also on all these installations, logging in fails to report date last logged in. Reinstalling issue-generator hasn't helped.

...

# inxi -S System: Host: msi85 Kernel: 6.6.30-1-longterm arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Tumbleweed 20240514 # systemctl list-units --type target --state active | grep graphical # systemctl status graphical.target ○ graphical.target - Graphical Interface Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; preset: disabled) Active: inactive (dead) Docs: man:systemd.special(7) # dmesg | grep issue # journalctl -b | grep issue # systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled # ls -glG /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue ls: cannot access '/etc/motd': No such file or directory ls: cannot access '/run/issue': No such file or directory lrwxrwxrwx 1 12 Apr 29 2022 /etc/issue -> ../run/issue -rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/70-eth0.conf

You configured your system to ignore generated IP address information and now you are asking why it ignores it?

The goals are: 1-to have unused VTs look like they did before there was systemd, a Welcome to ... line at top of screen, and nothing but black between it and login prompt a line or two or three below it. 2-to have passwd submission responded to with an announcement of last login.

...

-rw-r--r-- 1 0 Aug 18 2021 /etc/issue.d/90-openSUSE.conf -rw-rw-r-- 1 27 Oct 3 2015 /etc/motd.d/welcome # cat /etc/issue.d/* /etc/motd.d/* /etc/motd /etc/issue /run/issue Have a lot of MSI85 fun... cat: /etc/motd: No such file or directory cat: /etc/issue: No such file or directory cat: /run/issue: No such file or directory #

...

How can these installations be troubleshot? What else is missing? What's responsible for reporting last login timestamp? -- Evolution as taught in public schools is, like religion, based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On Thu, May 30, 2024 at 1:10 AM Felix Miata wrote:

...

issue-generator.service is WantedBy=default.target. Is default.target actually used during boot?

More often than not, no. Usually default is defined as graphical, but most boots are maintenance boots, so kernel cmdline includes a 3.

Which explains your problem.

I tried changing WantedBy from default to multi-user, but it didn't help.

Explain step by step what you did.

On 30.05.2024 17:44, Felix Miata wrote:

...

...

I tried changing WantedBy from default to multi-user, but it didn't help.

...

Explain step by step what you did.

# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot

I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.

On 2024-05-30 20:15, Felix Miata wrote:

Andrei Borzenkov composed on 2024-05-30 20:19 (UTC+0300):

...

Felix Miata wrote:

...

...

...

...

I tried changing WantedBy from default to multi-user, but it didn't help.

...

...

...

Explain step by step what you did.

...

...

# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot

...

I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.

Felix Miata composed on 2024-05-29 18:10 (UTC-0400):

...

...

...

# systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled

Looks enabled to me, whether on an installation where it works, or not. And, it works if I run

systemctl start issue-generator.service

on any where it doesn't.

He is saying that if you change the [install] section , you have to do a systemctl enable to activate that change. At least that is what I understand, it is news to me. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.5)

Op vrijdag 31 mei 2024 02:54:27 CEST schreef Felix Miata:

Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled; or issue-generator uninstalled, then installed? Restarting or rebooting I can understand, but not those pairs. systemctl daemon-reload systemctl restart whatever_service_you_added

-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team openSUSE Mods Team

On Fri, May 31, 2024 at 3:55 AM Felix Miata wrote:

Carlos E. R. composed on 2024-05-30 23:25 (UTC+0200):

...

Felix Miata wrote:

...

...

Andrei Borzenkov composed on 2024-05-30 20:19 (UTC+0300):

...

...

...

Felix Miata wrote:

...

...

...

...

...

> I tried changing WantedBy from default to multi-user, but it didn't help.

...

...

...

...

...

Explain step by step what you did.

...

...

...

...

# systemctl edit /etc/systemd/system/issue-generator.service copy [Install] WantedBy=multi-user.target from lower part of file to ~line 3 s/graphical/multi-user/ save/exit # Reboot

...

...

...

I would expect that a user who constantly talks about managing dozens if not hundreds systems knows that to apply [Install] section one needs to enable unit.

...

...

Felix Miata composed on 2024-05-29 18:10 (UTC-0400):

...

...

...

...

...

# systemctl list-unit-files | grep issue issue-generator.path enabled enabled issue-add-ssh-keys.service disabled disabled issue-generator.service enabled enabled

...

...

Looks enabled to me, whether on an installation where it works, or not.

That is a common misunderstanding. The "enable(d)" as used in systemd has nothing to do with the colloquial usage of the English word "enable(d)". "enable" in systemd means exactly that - create links defined by [Install] section. "enabled" in systemd means exactly that - links defined by [Install] section exist. Now you hit a case when some links are present and some links are missing. This unit is neither fully enabled nor completely disabled. systemctl apparently shows "enabled" if any link is present. Showing "disabled" in this case would be just as wrong. Maybe it should show "partially enabled" (or similar) to avoid confusion. That is something you need to bring up with upstream.

...

...

works if I run

...

...

systemctl start issue-generator.service

...

...

on any where it doesn't.

...

He is saying that if you change the [install] section , you have to do a systemctl enable to activate that change. At least that is what I understand, it is news to me.

Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled;

Quoting "man systemd.unit" Unit files may include an [Install] section, which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1) You do not need to run "systemctl disable" if you just add an additional link. You obviously need to do it if you replace one link with another - and you need to do it *before* changing the [Install] section, otherwise "systemctl disable" will not know what old link to remove.

or issue-generator uninstalled, then installed?

In this case installing the issue-generator would run "systemctl enable".

Andrei Borzenkov composed on 2024-05-31 10:19 (UTC+0300):

On Fri, May 31, 2024 at 3:55 AM Felix Miata wrote:

...

...

...

Felix Miata composed on 2024-05-29 18:10 (UTC-0400):

...

...

...

...

...

> # systemctl list-unit-files | grep issue > issue-generator.path enabled enabled > issue-add-ssh-keys.service disabled disabled > issue-generator.service enabled enabled

...

...

...

Looks enabled to me, whether on an installation where it works, or not.

That is a common misunderstanding. The "enable(d)" as used in systemd has nothing to do with the colloquial usage of the English word "enable(d)".

"enable" in systemd means exactly that - create links defined by [Install] section. "enabled" in systemd means exactly that - links defined by [Install] section exist.

Now you hit a case when some links are present and some links are missing. This unit is neither fully enabled nor completely disabled. systemctl apparently shows "enabled" if any link is present. Showing "disabled" in this case would be just as wrong. Maybe it should show "partially enabled" (or similar) to avoid confusion. That is something you need to bring up with upstream.

...

Are you two somehow suggesting that if a service override is created, it isn't implemented until the service is first disabled, then enabled;

Quoting "man systemd.unit"

Unit files may include an [Install] section, which carries installation information for the unit. This section is not interpreted by systemd(1) during runtime; it is used by the enable and disable commands of the systemctl(1)

You do not need to run "systemctl disable" if you just add an additional link. You obviously need to do it if you replace one link with another - and you need to do it *before* changing the [Install] section, otherwise "systemctl disable" will not know what old link to remove.

...

or issue-generator uninstalled, then installed?

In this case installing the issue-generator would run "systemctl enable".

On an obstinate host msi85 TW with graphical.target default, ultimately I: 1-changed default target from graphical to multi-user 2-rebooted without 3 on cmdline to find issue-generator started 3-changed default target from multi-user to graphical 4-rebooted 5-uninstalled issue-generator 6-removed /etc/issue 7-removed /etc/issue.d/ 8-removed /etc/sysconfig/issue-generator 9-rebooted 10-installed issue-generator 11-rebooted with 3 on cmdline to find issue-generator not started 12-rebooted without 3 on cmdline to find issue-generator started 13-created override to want multi-user instead of default 14-disabled issue-generator 15-enabled issue-generator 16-rebooted with 3 on cmdline to find issue-generator working as expected The question remains why necessary on this installation and not on most others with same default target graphical but 3 on grub's linu line? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata