serial-getty@.service: Allow device to fast fail if it does not exist

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.  When used together
this has the undesired side effect that systemd will wait until its
internal time out value of 90 seconds 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 "BindsTo" directive is replaced by the combination of the "PartOf"
and the "ConditionPathExists" directives.  The "After" directive is
unchanged because that will wait for the udev rules to process.  The
"PartOf" directive will issue a stop to the getty service if the
device goes away, similar to the "BindsTo" directive.  The
"ConditionPathExists" is what allows the service to fail fast vs
waiting for the timeout.  When a USB device is not plugged in at boot
you would find a message in the system journal like:

    systemd[1]: Condition check resulted in Serial Getty on \
                 ttyUSB0 being skipped.

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.wessel@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 2 insertions, 1 deletions

diff --git a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
index e8b027e97de..15af16a9f84 100644
--- a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
+++ b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty@.service
@@ -9,7 +9,8 @@
 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
+PartOf=dev-%i.device
+ConditionPathExists=/dev/%i
 After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
 After=rc-local.service