Some BSPs use a USB serial port which may or may not actually be
plugged all the time. It is quite useful to have a USB serial port
have a getty running but it does not make sense to wait for it for 90
seconds before completing the system startup if it might never get
plugged in. The typical example is that a USB serial device might
only need to be plugged in when debugging, upgrading, or initially
configuring a device.
This change is somewhat subtle. Systemd uses the "BindsTo" directive
to ensure existence of the device in order to start the service as
well as to terminate the service if the device goes away. The "After"
directive makes that same relationship stronger, and has the undesired
side effect that systemd will wait until its internal time out value
for the device to come on line before executing a fail operation or
letting other tasks and groups continue. This is certainly the kind
of behavior we want for a disk, but not for serial ports in general.
The kernel module loader and device detection will have run a long
time before the getty startup. By the time the getty startup occurs
the system has all the serial devices its going to get.
If you want to observe the problem with qemu, it is easy to replicate.
Simply add the following line to your local.conf for a x86-64 qemu
build.
SERIAL_CONSOLES="115200;ttyS0 115200;ttyUSB0"
Login right after the system boots and observe:
root@qemux86-64:~# systemctl list-jobs |cat
JOB UNIT TYPE STATE
1 multi-user.target start waiting
69 serial-getty@ttyUSB0.service start waiting
64 getty.target start waiting
71 dev-ttyUSB0.device start running
62 systemd-update-utmp-runlevel.service start waiting
5 jobs listed.
You can see above that the dev-ttyUSB0.device will block for 1min 30
seconds. While that might not be a problem for this reference build.
It is certainly a problem for images that have software watchdogs that
verify the system booted up all the way to systemd completion in less
than 90 seconds.
This other nice effect of this change is that the fast fail device
extend to additional serial ports that may not exist on ARM BSPs or
that might be configured in or out by the dtb files on different
boards.
Signed-off-by: Jason Wessel <jason.wes...@windriver.com>
---
.../systemd/systemd-serialgetty/serial-getty@.service | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
index e8b027e97d..a20092a173 100644
--- a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
+++ b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
@@ -10,7 +10,7 @@ Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
-After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
+After=systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service
# If additional gettys are spawned during boot then we should make
--
2.21.0
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
