В Tue, 21 May 2013 15:17:23 -0700 Kaz Kylheku <[email protected]> пишет:
> > On Thu, 16 May 2013 19:58:35 +0400, Andrey Borzenkov > <[email protected]> wrote: > > В Wed, 15 May 2013 21:19:38 -0700 > > Kaz Kylheku <[email protected]> пишет: > > > >> > >> Can you at least tell me how to get agetty to start on a system > >> that does not have my patch, when a USB-Serial converter is > >> inserted which is marked as a console? > >> > > > > The usual stanza is to use in your udev rules > > > > TAG+="systemd", ENV{SYSTEMD_WANTS}+="[email protected]" > > > > You probably can also check whether device is marked as console > > (whatever it means) in the same rule. > > > > TAG is likely to be already present for serial devices. > > Hi Andrey, > > Thank you very much for this hint in the right direction, > it was helfpul. I have made a lot of progress with this, > including additional kernel work, and only one more issue > remains (to my knowledge so far, pending more testing). > In all other respects, it works ideally, as I envisioned > it. > > One thing which was causing a problem that I had the USB > serial console declared on the kernel command line as the > rightmost console entry. If it is the rightmost console, then > it gets special treatment from systemd (which is entirely > justified, since the rightmost console device which is present > also gets special treament from the system: for instance > the /dev/console tty device always binds to the rightmost > console that is up.) In this case, if we have an additional > udev rule to do the getty service, it conflicts with built in > systemd behavior. The solution is not to have the USB serial > as the rightmost console (which means it cannot be the only > console: but that makes sense: we should not have a device that > can be removed as the only console!) > > Now then, I have added two sysfs attributes to USB serial > devices which make it easier to write accurate udev rules. > > My udev rule looks like this: > > SUBSYSTEM=="tty", KERNEL=="ttyUSB[0-9]", ATTRS{is_console}=="1", > ATTRS{reinserted}=="0", TAG+="systemd", > ENV{SYSTEMD_WANTS}+="getty@%k.service" > > We only launch agetty when a ttyUSB device appears which is > a console, and is not a re-insertion. > > The "reinserted" property is only set when the device is > reinserted and a TTY session is recovered. If there is > completely a fresh start, then this property goes back > to zero. > > The agetty killing behavior is prevented by setting > KillMode = none in the getty service, so when the device > is pulled and re-inserted, the shell session is intact. > > *** > > So now only one issue remains. If I have s shell session > open and during that session I pull the tty serial device > and plug it back in, and then log out of that session, > systemd does not serve up agetty. The shell logs out and > then the console goes unresponsive with no program monitoring > it. > > The workaround is, at that point, to unplug the device > and plug it back in. This will trigger a udev event (with > the "reinserted" attribute equal to "0": since no TTY session is > being recovered: nothing has the TTY open). The custom udev > rule fires, and systemd serves up an agetty. > Do you use [email protected] template that is distributed with systemd? If not, could you show full service definition? BTW it should probably be getty-serial (not that it matters for this problem). > systemd seems to be reacting to the device removal event, > and basically goes into a state in which it thinks the device is > gone, which is correct. Moreover, since KillMode = none > is in effect, it does not turf the associated session. However, > it does not notice that the device is reinserted. > When that session exits spontaneously due to a logout, > systemd still thinks the device is not there any more, > and so does not re-start the agetty. > > I suspect that this cannot be "configured away", but will > require a patch to systemd. Though it's only a minor issue now. > The users can just be trained to do a pull and re-insert as > a workaround when a login prompt does not appear. > > Compared to the great convenience of how everything works now, > it's nothing. > > Thanks again for the tip ... _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
