[oe-commits] [openembedded-core] 02/02: serial-getty at .service: Allow device to fast fail if it does not exist

[git at git.openembedded.org]

This is an automated email from the git hooks/post-receive script.

rpurdie pushed a commit to branch master-next
in repository openembedded-core.

commit 8893ad919173326d782a49d0031bb25872577168
Author: Jason Wessel <jason.wessel at windriver.com>
AuthorDate: Tue Aug 20 17:27:50 2019 -0700

    serial-getty at .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, 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 at qemux86-64:~# systemctl list-jobs |cat
       JOB UNIT                                 TYPE  STATE
         1 multi-user.target                    start waiting
        69 serial-getty at 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 at windriver.com>
    Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
---
 meta/recipes-core/systemd/systemd-serialgetty/serial-getty at .service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty at .service b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty at .service
index e8b027e..a20092a 100644
--- a/meta/recipes-core/systemd/systemd-serialgetty/serial-getty at .service
+++ b/meta/recipes-core/systemd/systemd-serialgetty/serial-getty at .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

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.