Prevent getty(8) from looping if the device node doesn't exist.

[trasz]

Summary

Prevent getty(8) from looping indefinitely if the device node doesn't
exist. This behaviour makes no sense for eg USB serial adapters, or
USB device-side serial templates.

This kind of reverts to pre-r135941 behaviour.

[imp]

So rather than this looping, what will happen is that init will loop now spawning this program. Is that desired?

[trasz]

Well, if it was specified in ttys as "on", that's what would happen. But it's supposed to be used with "onifexists", or perhaps "onifconsole".

[imp]

In D14198#297780, @trasz wrote:

Well, if it was specified in ttys as "on", that's what would happen. But it's supposed to be used with "onifexists", or perhaps "onifconsole".

I think people will notice the extra forking / execing of getty is my point...

[imp]

There's a bit of a mismatch. From init.c:

       /*
         * Attempt to open the device, if we get "device not configured"
         * then don't add the device to the session list.
         */
        if ((fd = open(sp->se_device, O_RDONLY | O_NONBLOCK, 0)) < 0) {
		if (errno == ENXIO) {
                        free_session(sp);
                        return (0);
                }
        } else
                close(fd);

Notice that ENXIO is what triggers here. However, since devfs has entered the system, this turns into a ENOENT. It sounds like the obvious way to fix this is to have that as a special case, but people have been using init to keep programs alive with entries that specify something that doesn't exist so that ENXIO isn't triggered.

The worst that will happen with this change is the dreaded spawning too fast messages, but at least that's a visible indication of the problem. So I'm inclined to say this change is OK as is. It might be better, though , to try a couple of times before giving up rather than looping forever regardless of why. I think this loop is there so that we come back in a sane amount of time after using tip or cu to call out on a tty that otherwise used for login.

So the different scenarios apart from running getty on a usb serial device that no longer exists should be analyzed.

[trasz]

I tried digging a little, and unfortunately the loop comes from before our repo history starts - r1593, which is some RCS repo surgery by rgrimes@. I have no idea what's the original purpose of it, and given there's some esoteric functionality there - mostly related to chat scripts - that I'm not able to easily test, I'd prefer to leave it as it is. It's been there forever, someone might depend on it.

Regarding init(8) looping - that's true, but it's intended to be used with "onifexists", which won't loop when the device disappears.

So - is it ok? Can you mark it as accepted? Thanks!

[imp]

In D14198#299943, @trasz wrote:

I tried digging a little, and unfortunately the loop comes from before our repo history starts - r1593, which is some RCS repo surgery by rgrimes@. I have no idea what's the original purpose of it, and given there's some esoteric functionality there - mostly related to chat scripts - that I'm not able to easily test, I'd prefer to leave it as it is. It is been there forever, someone might depend on it.

Regarding init(8) looping - that's true, but it's intended to be used with "onifexists", which won't loop when the device disappears.

So - is it ok? Can you mark it as accepted? Thanks!

I still have real reservations about this. onifexists is barely a year or two old. The default /etc/ttys will cause a getty-fork bomb as fast as getty can spawn with this change on some systems that don't use onifexists or onifconsole. Well, the old default /etc/ttys did this, the newer ones seem to be OK. It's still wrong to not rate limit know fork-bombs :(

[trasz]

But we do limit it. Here's what happens:

Feb 24 15:03:18 v2 getty[840]: open /dev/meh: No such file or directory
Feb 24 15:03:18 v2 getty[841]: open /dev/meh: No such file or directory
Feb 24 15:03:18 v2 getty[842]: open /dev/meh: No such file or directory
Feb 24 15:03:18 v2 getty[843]: open /dev/meh: No such file or directory
Feb 24 15:03:18 v2 init: getty repeating too quickly on port /dev/meh, sleeping 30 secs

So, instead of a single warning per minute in the logs now you get five lines per 30 seconds, but it's not the end of the world.

How about committing, but without MFC?

[imp]

OK.