Re: RfC: Hurd console by default
The hurd console-client requires ttys to be already "attached" to [1],
which is why the patch in question runs the console *after* runttys in
/libexec/runsystem.gnu. The console-client will segfault if one
attempts to run it before the ttys are established (like in init).
I'd like to see the console-client fixed so that it not blank the
screen etc., until there is at least one tty setup.
The patch in question fails to pass signals to runttys. Instead the
signals are ignored. A better solution would allow runttys to be
restarted via a signal, and the hurd console would react sanely.
1. This business of a tty being "attached" to means that a program
(like login or getty i'm not precisely sure) has opened a /dev/tty#
file that is being provided by a /hurd/term translator. This action
triggers the console-server /hurd/console to start providing a virtual
console in the /dev/vcs/# directory on the fly. The console-client
requires the console-server to be providing these virtual consoles.
On Wed, 09 Mar 2005 17:29:32 +0100, Alfred M. Szmidt <ams@kemisten.nu> wrote:
> Some DMs like GDM do detect such tight-loop error, and stop
> retrying, which makes the console usable again after a few
> tries. The Hurd console may probably use such way.
>
> Implementing such a thing in the actual console is silly, use another
> program like /sbin/init to handle the respawning.
>
>
> --
> To UNSUBSCRIBE, email to debian-hurd-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: