0

Due to (what I think is) some sort of bug on the Linux version (Kali v2.0) of my remote computer, my TTY text consoles do not start until I locally sit on the machine and press CtrlAltFn.

I use to remotely login via SSH into that computer, and then I access the TTY n by using ConSpy, so, for example:

# conspy 6

sends my SSH client (Putty in my case) to TTY6.

But, as long as TTY consoles have not started, I only get a blank screen with the cursor blinking.
So I firstly send:

# agetty 38400 tty6 &

And then the TTY6 starts running, so this time I can login and interact, but I get this strange message:

Kali GNU/Linux 2.0 kali tty6
kali login: luis
Password:
Linux kali 4.0.0-kali1-686-pae #1 SMP Debian 4.0.4-1+kali2 (2015-06-03) i686

The programs included with the Kali GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Kali GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
-bash: cannot set terminal process group (3662): Inappropriate ioctl for device
-bash: no job control in this shell

Is the agetty command the proper method to spawn a TTY text virtual console?

Sopalajo de Arrierez
  • 6,481
  • 2
    is there any reason you need to attach to a TTY when ssh already gives you a shell every bit as good? are you re-inventing GNU screen or tmux? – cas Oct 05 '15 at 05:37
  • 2
    BTW, i suspect your problem is because Kali 2.0 is based on Debian jessie, which has switched to systemd. Systemd starts gettys on demand. See http://unix.stackexchange.com/questions/56531/how-to-get-fewer-ttys-with-systemd – cas Oct 05 '15 at 05:47
  • @cas : Just a example: if you (remotely) order cp HugeFile /Destination/Path via SSH, there is a risk for connection (internet) hangups to break (mess) the full process. If you (remotely) order cp on (remote) TTY there is no such risk. – Sopalajo de Arrierez Oct 05 '15 at 06:48
  • 1
    Read about nohup, screen, tmux and maybe batch and at... –  Oct 05 '15 at 06:58
  • 1
    @SopalajodeArrierez: as i thought, you're (partially) reinventing screen etc. they all solve that problem (and a lot more) – cas Oct 05 '15 at 07:11
  • @casm indeed, screen is another way of doing the same remote tasks I do on TTYs. Having alternatives is always a good idea. – Sopalajo de Arrierez Oct 05 '15 at 13:07

1 Answers1

2

This is by design.

Due to (what I think is) some sort of bug on the Linux version (Kali v2.0) of my remote computer, my TTY text consoles do not start until I locally sit on the machine and press CtrlAltFn.

This is not a bug. This is systemd Linux working as designed. TTY login services for kernel virtual terminals are started on demand by logind, as they are switched into the foreground. If you are accessing the the machine remotely and using ConSpy, you are of course not switching kernel virtual terminals into the foreground.

Is the agetty command the proper method to spawn a TTY text virtual console?

Yes, and no. Yes, it's the way to spawn a getty/login service. No, it doesn't spawn the virtual terminal itself. No, you don't run it directly.

As stated, logind does this. There's a systemd service, named autovt@ttyN.service, for each virtual terminal. That is what runs agetty. One starts that service manually, or lets logind start it upon demand.

The problems of screen and tmux with systemd.

Of course, as noted you are using the kernel's virtual terminal subsystem and ConSpy as the server and client parts of a system like screen or tmux. You could switch to using screen or tmux.

The problem with screen and tmux is that they don't interoperate well with systemd. This is a known systemd problem, and is also by design. If you start the server part of screen or tmux from within a login session that is managed directly as a service by systemd (as autovt@ttyN.service services are, and as indeed sshd@connection.service services are when running SSH in Accept=yes mode) then systemd kills the server when you log out, because by design it kills all still-left-around processes within a service when that service terminates, and logging out of such login session services counts as termination.

The world has a choice of workarounds for this design conflict, include such things as changing the kill mode of sshd@.service. By far the best approach is to make the screen or tmux server itself into a managed service. You thus don't start screen or tmux by logging in and running it interactively. You start it by having it as a fully-fledged service that is started and stopped via systemd.

At which point, all of the stuff in screen and tmux to fork off a server process in the background is at best overengineered, as the background server part is all that a systemd-managed screen or tmux service needs to do, and it doesn't need to "dæmonize" its server. (Ironically, the problem that screen and tmux have with systemd is yet another example of why it is actually impossible to safely, securely, and reliably "dæmonize" from an interactive login session.)

Alternatives

Since you mention alternatives, here is another: nosh has a user-space virtual terminal system. You could run the nosh service manager under systemd, and some of the nosh ttylogin@vcN-tty and terminal-emulator@vcNservices under it, talking to the emulated terminals from SSH login sessions with console-ncurses-realizer. (If you adjusted ConSpy to not hardwire device names as it currently does, you could even view the emulated terminals with ConSpy, since there's a vcsa-compatible display buffer available.) console-terminal-emulator doesn't "dæmonize" and does just the one job, of emulating a terminal and sitting between the master side of a pseudo-terminal and the emulated display and input.

There are a couple of incidental benefits of this: It's not constrained by kernel-space design constraints, and so is a more complete DEC VT emulation than the emulator programs built into kernels. Terminals can be resized with the ordinary DEC control sequences, to arbitrary sizes. Terminals auto-reset, for security, immediately on log-off rather than on next invocation of log-on.

Further reading

JdeBP
  • 68,745