[systemd-devel] How to get systemd to leave a USB serial console session alone when hadware is pulled?
Kaz Kylheku
kaz at kylheku.com
Wed May 15 16:32:12 PDT 2013
Hi all,
I have a system that is configured to have a ttyUSB0 as a console.
To improve this, I patched the Linux kernel to create a cool feature:
when a USB Converter is removed, although the `/dev/ttyUSB<n>` entry
disappears, existing file descriptors which have that tty device open
are undisturbed. Processes that are blocked on a tty read do not so
much
as wake up. Writes go to the bit bucket. When hardware re-appears and
`/dev/ttyUSB<n>` comes back to life, those tty file descriptors are
re-attached, and I/O nicely resumes. (Even if different hardware is
plugged in: remove a PL2303 and plug in an FTDI, and your tty is
back.)
What's wrecking things is systemd:
1. systemd does not serve up an `agetty` on the port,
unless the hardware is already inserted before the system
boots up.
2. If the hardware is pulled, then systemd kills the session.
It kills agetty and all its progeny, whether there is a logged
in shell session on the console or not.
3. Thirdly, systemd will not serve up `agetty` when the hardware is
re-inserted even if it previously started `agetty` on that port.
It notices the removal, but not the reinsertion.
How can we configure systemd not to kill the session if the tty device
is removed, but only to ensure that all console devices have
an agetty?
If it can't be configured, I'd appreciate some pointers about
where to look in the code.
I'm looking at the systemd code now but it's quite incomprehensible.
There are few comments, and since the program is broken into many
small
programs, you can't easily follow a call graph, or put a breakpoint
somewhere and see how that point was called.
Is there some detailed design documentation, or some kind of hacker's
guide to the internals which would describe "such and such
responsibility
is handled here, which generates such and such events that some other
thing over here responds to" with a block diagram, perhaps.
Thanks.
More information about the systemd-devel
mailing list