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@vcN
services 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
screen
ortmux
? – cas Oct 05 '15 at 05:37systemd
. 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:47cp HugeFile /Destination/Path
via SSH, there is a risk for connection (internet) hangups to break (mess) the full process. If you (remotely) ordercp
on (remote) TTY there is no such risk. – Sopalajo de Arrierez Oct 05 '15 at 06:48nohup
,screen
,tmux
and maybebatch
andat
... – Oct 05 '15 at 06:58screen
etc. they all solve that problem (and a lot more) – cas Oct 05 '15 at 07:11screen
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