Place kmscon in all VTs when kmscon.service is enabled be default?

[trusktr]

When kmscon.service is enabled, kmscon gets placed in tty2 (is it the first tty available?).

IMHO, and if possible, a better behavior would be to place kmscon in all VTs which are usually tty1-6. Is it possible to modify/add systemd units so that enabling kmscon.service is all that is required, without having to do ln -s /usr/lib/systemd/system/kmsconvt@.service /etc/systemd/system/autovt@.service?

It'd be nice if enabling kmscon.service put kmscon in all VTs while enabling only specific a kmsconvt@ttyX.service unit would target a ttyX on boot (I noticed this is not the case).

[cl91]

Well... why would this be the desired behavior? kmscon has an option to specify which tty to use. And if it is not specified, it uses the first one that is found.

When kmscon.service is enabled, kmscon gets placed in tty2 (is it the first tty available?).

IMHO, and if possible, a better behavior would be to place kmscon in all VTs which are usually tty1-6. Is it possible to modify/add systemd units so that enabling kmscon.service is all that is required, without having to do ln -s /usr/lib/systemd/system/kmsconvt@.service /etc/systemd/system/autovt@ .service?

It'd be nice if enabling kmscon.service put kmscon in all VTs while enabling only specific a kmsconvt@ttyX.service unit would target a ttyX on boot (I noticed this is not the case).

— Reply to this email directly or view it on GitHubhttps://github.com/dvdhrm/kmscon/issues/97 .

[trusktr]

That's true about kmscon accepting the --vt argument. What I mean is that perhaps the kmscon.service unit can be modified somehow to start kmscon on each available VT.

I noticed that regardless of whether kmscon.service is enabled, doing `ln -s /usr/lib/systemd/system/kmsconvt@.service /etc/systemd/system/autovt@.service' results in kmscon replacing agetty in all VTs no matter what. I also noticed that kmsconvt@.service is always enabled, and cannot be disabled.

The reason I ask about this is because it'd be nice to be able to enable/disable kmscon using only systemd. It's very easy to forget that I must delete the autovt@.service symlink in order to disable kmscon. That defeats the purpose of using systemd to manage services. Get what I mean?

Here's an example ideal use case: the user want to run kmscon specifically on tty4 after each boot, and he has no kmscon-related services enabled. All he would have to do is systemd enable kmsconvt@tty4, which is much nicer than creating a symlink. Alternatively, if the user wants to run it in tty4 just one time (no boot), the command would be systemd start kmsconvt@tty4 (which I think already works).

It's easier to explain what I'd like like this:

if kmscon.service is enabled
    start kmscon in each VT
else
    for each kmsconvt@ttyX.service that is enabled
        start kmscon on ttyX

[trusktr]

I noticed that running systemd disable kmsconvt@.service removes the manually created symlink, which is nice.

Here's another possible way to set this all up:

if kmscon.service is enabled
    if any kmsconvt@ttyX.service is enabled
        for each kmsconvt@ttyX.service that is enabled
            start kmscon on ttyX
    else
        start kmscon in each VT
else
    don't start kmscon at all no matter what (which currently happens with the manual symlink)

[dvdhrm]

This is already possible. Please read the systemd documentation for that. But lets clear some things up:

• kmscon will never start itself on all VTs. In default setups, there are 64 VTs (nearly all of them unused) and it would be a waste of resources to start kmscon on all of them.
• systemd-logind is responsible of starting "agetty" on TTYs. It does this by starting autovt@ttyX.service. In normal systems, this is symlinked to getty@ttyX.service and thus, getty is started. If you relink autovt@.service to kmsconvt@.service, then kmscon will be used instead of agetty.
• kmscon.service is deprecated. It starts kmscon on the first available VT (which is tty2 if tty1 is used by systemd for boot messages). Please always use kmsconvt@.service
• If you want to start kmscon on a given VT once, then use systemctl start kmsconvt@ttyX.service
• kmsconvt@.service is not always enabled. This is wrong, I don't know why you would think that?

So for your setup, please do:

• If you want kmscon to be enabled on all VTs, please link autovt@.service to kmsconvt@.service
• If you want kmscon to be enabled on a limited number of VTs, please run systemd enable kmsconvt@ttyXY.service for each TTY you want kmscon to run on
• If you don't want kmscon to be enabled by default, don't do anything! Don't link autovt@.service, don't enable kmsconvt@.service, just don't touch anything at all. This is the default behavior.

I hope that helps Cheers David

[trusktr]

Thanks for the helpful reply.

kmscon will never start itself on all VTs. In default setups, there are 64 VTs (nearly all of them unused) and it would be a waste of resources to start kmscon on all of them.

What I meant was to put them in all active ttys. On my setup it's just tty1 through tty6. What is it about systemd that specifically starts agetty on tty 1 through 6? Why not 1 through 12?

systemd-logind is responsible of starting "agetty" on TTYs. It does this by starting autovt@ttyX.service. In normal systems, this is symlinked to getty@ttyX.service and thus, getty is started. If you relink autovt@.service to kmsconvt@.service, then kmscon will be used instead of agetty.

By default, my system does not have any autovt* systemd-related file. Here's some console output:

┌─[03:12:01/starlancer/root/~]
└─╼ systemctl enable autovt@.service 
Failed to issue method call: No such file or directory

┌─[03:13:03/starlancer/root/~]
└─╼ l /etc/systemd/system/autovt@.service
ls: cannot access /etc/systemd/system/autovt@.service: No such file or directory

So this is why I felt that making a symlink manually felt a bit odd. Am I supposed to have this file by default? Even without it, all six of my linux TTYs (agetty) work just fine. The weird thing is that typing systemctl enable auto then pressing tab autocompletes it to systemctl enable autovt@.service though no such file exists.

kmscon.service is deprecated. It starts kmscon on the first available VT (which is tty2 if tty1 is used by systemd for boot messages). Please always use kmsconvt@.service If you want to start kmscon on a given VT once, then use systemctl start kmsconvt@ttyX.service

Thanks! will do. Removing kmscon.service might reduce possible confusion for new comers.

kmsconvt@.service is not always enabled. This is wrong, I don't know why you would think that?

I could've sworn that's what the output was saying. It's gone now and the output lost after restart. I hope I'm not going crazy. lol

If you want kmscon to be enabled on all VTs, please link autovt@.service to kmsconvt@.service

This is the part I feel awkward about. It seems like the user should not have to link anything. It seems like the purpose of using systemd is to avoid doing such things manually.

If you want kmscon to be enabled on a limited number of VTs, please run systemd enable kmsconvt@ttyXY.service for each TTY you want kmscon to run on

This would be nice, but look at this output:

┌─[03:32:37/starlancer/root/~]
└─╼ systemctl enable kmsconvt@tty3.service
ln -s '/usr/lib/systemd/system/kmsconvt@.service' '/etc/systemd/system/getty.target.wants/kmsconvt@tty1.service'

Shouldn't the output show kmsconvt@tty3.service instead of kmsconvt@tty1.service? It seems like no matter what I put for the XY in ttyXY, it creates only the link using tty1, which seems to imply that kmscon is only enabled for tty1 (which get's replaced by GDM anyways).

If you don't want kmscon to be enabled by default, don't do anything! Don't link autovt@.service, don't enable kmsconvt@.service, just don't touch anything at all. This is the default behavior.

This actually works, I just didn't know that kmsconvt@tty1.service was enabled, which was throwing me off. Also, the output of systemd is not always helpful. For example, if kmsconvt@tty1 is enabled, typing systemctl disable kmsconv autocompletes to systemctl disable kmsconvt@.service. I would expect to see kmsconvt@tty1.sevice, etc, depending on which ones I've enabled. I bet this is a systemd bug though.

All in all: If you guys could find some way to avoid the user having to make a symlink manually, that'd be great. It seems like a hack. If you could keep the kmscon.service and somehow make it shorthand for creating the symlink when enabling it, and deleting the symlink (that seems to be system default) when disabled, that'd be super awesome.

[dvdhrm]

systemd-logind spawns gettys. So look into /etc/systemd/logind.conf to configure the number of gettys that are spawned. Also see "man logind.conf" or "man systemd-logind" (or whatever it is called ;)).

The autovt@.service symlink can be found in: /lib/systemd/system/autovt@.service And it is symlinked to "getty@.service" by default.

The systemctl enable kmsconvt@tty3.service looks like a serious bug. It should definitely create the symlink to tty3, not tty1. You might want to report it upstream.

So this all is actually systemd-related and I cannot do anything about it. The systemd people recommend doing symlinks yourself so I won't interfere. Same for any debug/info output of systemctl. Sorry. I only provide the service files, everything else is left to systemd.

[trusktr]

Hey, I filed a report about the bug (your second to last paragraph in the last comment), and they said to change the line Alias=getty.target.wants/kmsconvt@tty1.service to WantedBy=getty.target. More details here: https://bugs.freedesktop.org/show_bug.cgi?id=66643

[trusktr]

I post another issue on the systemd bugzilla. Zbigniew Jedrzejewski-Szmek replied, saying that the symlink in /etc/ doesn't need to be created manually, and we can use strictly systemd to enable kmscon with another small mod to the unit file: https://bugs.freedesktop.org/show_bug.cgi?id=66889

[dvdhrm]

Thanks a lot for digging into this! I fixed the "WantedBy" issue. The "Alias=" thingy doesn't work with "systemctl disable", which is pretty bad. I am talking to systemd people on IRC to figure out what to do.

Seems like "systemctl disable" is quite broken in that regard. Try adding the "Alias=autovt@%i.service" line and then try: systemctl enable kmsconvt@tty3.service followed by systemctl disable kmsconvt@tty3.service (or use kmsconvt@.service or whatever you want)

You will notice that the autovt symlink is not removed. This is bad because users might enable kmscon for testinig but cannot disable it again (without manual intervention). I will leave this bug open until someone fixes systemd-disable to do that. If will try to mention it in Brno in August during the next systemd-hackfest.