By default inittab allows starting console login `askfirst:/usr/libexec/login.sh`. If I remove it the script is not started on boot and there's no console login access. Great. But what would be the proper way to start console login script from some system daemon after init completed inittab processing? And then stop it when needed?
Would just service in /etc/init.d be sufficient and right way starting script as daemon?
Thanks. I think I need to give more background. There will be another device connected to the console port in parallel (well, not exactly) to the terminal, which will be queried through the /dev/console. For transfers to work properly I need to stop all the console consuming devices for the time data transfer takes place. System services restart is not an option; network restart is not an option. I just need console monitor to stop and then start. Normally when I just kill it, it is being immediately respawned by the system.
Edit: it seems I may be incorrect thinking that login.sh is the thing I need to stop. With console login disabled I just get console access without login, therefore something deeper in the system using the device file/port. At the same time if I comment that inittab line for console login I get no console prompt after reboot - what I actually need, but without understanding (so far) how to start and stop it again.
Yes, this is another problem to solve. If you mean data corruption due to several devices writing to the same serial port, it is still to be checked. I hope relatively short writes will be atomic. If not, then I will also need to find a way how to prevent kernel writing data while I write data to the serial port.
Update: the user space writes are not atomic. Kernel writes are atomic. Bad news. I may need a kernel driver/module.
Update 1: I think problem is solved. I may simply perform request to additional device using kernel message. There's no need to write anything to the console separately/concurrently. Re: receive, the additional device will physically disconnect the upstream console device when responding.
There's still a question for receiving side - how to stop kernel listening to console port.
Then I will not have console at all. I need to turn the console "off" for some time. I need console in general, but it is ok not to have it within the time interval when another device is being communicated with.
and if I run askfirst /usr/libexec/login.sh from the ssh session it does exactly what I need, now I need to figure out how to run it for specific terminal, in this case /dev/ttyS0.
Quite frankly, don't. It will never work.
ROM init, several bootloader stages, kernel, procd and getty will use ttyS0 at their own leisure.
If you want the functionality, check if there are test points for a secondary ttyS1 somewhere accessible - or simply use an usb2serial dongle. That way you leave the main system console alone, but gain exclusive access to the addon serial port for your needs.
I do not have more ports. That's original problem.
This partially works. I can log in when this is running as daemon, BUT if I run e.g. logread -f in terminal it does not respond to ^C and any other control sequences. And error is "can't access tty; job control turned off". Same behavior when using /dev/ttyS0.
Any idea what's the problem and how to fix it?
Let's try anyway! The main issue now is to ensure there' no one within the system having console serial port open so that it steals data from the target receiver.
in the daemon does the trick. After daemon is stopped all child processes spawned within the terminal are being killed, so no need to kill them manually.
Bonus functionality is by stopping daemon remotely you prevent local console access.