RFE: agetty: consider /usr/lib/issue as fallback for /etc/issue

[poettering]

It would be great if agetty would look for /usr/lib/issue as fallback for /etc/issue, if it is missing.

In systemd we recently (systemd/systemd#13154) started to copy in an issue file to /etc/issue if the file was missing, in order to support systems that are booted up with an empty /etc. I'd like to get rid of this again, and would prefer if agetty would maybe just use a file in /usr/lib/issue if /etc/issue is not there, so that /etc becomes entirely redundant for it.

As it turns out Fedora already ships such a file in /usr/lib/issue, and symlinks /etc/issue to it as part of the fedora-release package. It would be fantastic if that symlink wouldn't even have to exist.

(and yupp /usr/lib/issue.d/ might be something to support too?)

(and while we are at it, maybe /run/issue.d/, too? so that during boot tools can write out messages there that are then shown at login time without having to modify /etc at all?)

[karelzak]

Sounds good, what is the right order to check the files and dirs, /etc -> /usr/lib -> /run/issue.d/ or /run should be the first attempt? (/run is empty after boot, so if there is /run/issue.d than it's probably because someone wants to use it.)

[poettering]

In systemd we generally check /etc first, /run second, and /usr last. Rationale: the first is user configuration, the second is runtime (usually generated) stuff and the third is vendor stuff. And explicit user config should always win over generated and vendor stuff, and generated over vendor stuff. Of course, one could argue that the user also might want to make manual runtime configuration, but I doubt this is going to be a common theme, and for the few cases where people really do want that they can use symlinks.

[poettering]

In case my proposed algorithm wasn't clear:

1. Use /etc/issue if it exists
2. Use /run/issue if it exists but step 1 didn't apply
3. Use /usr/lib/issue if it exists but neither step 1 nor 2 applied
4. Collect all snippets from /etc/issue.d/, /run/issue.d/, /usr/lib/issue.d/*, sort them by their path and extend the issue texts found in 1/2/3.

[thkukuk]

Please make /usr/lib/issue.d configureable. Many people don't like that /usr/lib is meanwhile crowded with configuration files, binaries and many other things and that there isn't a simple, single locations anymore in which you can look and grep for configuration options.
openSUSE will move all the wrongly places configurations files out of /usr/lib to another directory for that reason.

[karelzak]

Please make /usr/lib/issue.d configureable. Many people don't like that /usr/lib is meanwhile crowded with configuration files

The idea is to keep all the directories optional, and if you don't like /usr/lib that you can continue to use /etc without any extra option or compile time configuration. We want to be backwardly compatible in this case and the same binary has to work with /etc as well as with /usr/lib.

The directory /usr/lib is mostly for "empty-/etc" use-case or for distros where static defaults are in /usr/lib.

[thkukuk]

The directory /usr/lib is mostly for "empty-/etc" use-case or for distros where static defaults are in /usr/lib.

Correctly this is our use case and what we currently implement, except that we don't want to use /usr/lib but most likely /usr/etc for this.
The clear feedback on conferences, mailing lists and personal talks about this topic was: don't put this stuff in /usr/lib, it's hard to find anything there if you want to know how the configuration option is and what the default is.

[karelzak]

I don't see s problem to support more directories (it's just one access() call), including /usr/etc.

But it seems you want to use extra library (libeconf) to read the config files (at least according to #855), it's something completely different than one extra access()...

[thkukuk]

No, there are no plans from us to use libeconf to read the issue file, this doesn't make much sense. libeconf is for key/value configuration files.

[karelzak]

OK.

[karelzak]

Implemented.