> openvt: vt 1 is in use; command aborted
> use `openvt -f' to force.
The weird thing about this is that getty does no check on VT_GETSTATE, so it will happily let run multiple gettys on the same tty.
... os openvt looks a bit overzealous. tty1 only counts as "used" because it is assigned to the console inside the kernel ... which is probably a bad reason for refusing to run something on a vt. So this may a bizarre special case which happens if you try to use openvt with tty1 - nothing process appears to have tty1 open if you look with ls -l /proc/*/fd/ | grep 'tty\|console'
Re the upstart problems, it seems bizarre to start getty in tty1 and then kill it and run something else. I expect that upstart jobs of like the below weren't really part of the original thinking...
start on started x
exec stop x
Wouldn't it make more sense to have a linaro modification to the upstart package, which removes of modified the tty1 job?
> openvt: vt 1 is in use; command aborted
> use `openvt -f' to force.
The weird thing about this is that getty does no check on VT_GETSTATE, so it will happily let run multiple gettys on the same tty.
... os openvt looks a bit overzealous. tty1 only counts as "used" because it is assigned to the console inside the kernel ... which is probably a bad reason for refusing to run something on a vt. So this may a bizarre special case which happens if you try to use openvt with tty1 - nothing process appears to have tty1 open if you look with ls -l /proc/*/fd/ | grep 'tty\|console'
Re the upstart problems, it seems bizarre to start getty in tty1 and then kill it and run something else. I expect that upstart jobs of like the below weren't really part of the original thinking...
start on started x
exec stop x
Wouldn't it make more sense to have a linaro modification to the upstart package, which removes of modified the tty1 job?
Cheers
---Dave