[OE-core] [PATCH] serial-getty at .service: Allow device to fast fail if it does not exist
Richard Purdie
richard.purdie at linuxfoundation.org
Tue Aug 27 22:58:30 UTC 2019
On Tue, 2019-08-20 at 17:27 -0700, Jason Wessel wrote:
> 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>
> ---
> .../systemd/systemd-serialgetty/serial-getty at .service | 2
> +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Jason,
Somehow this change is responsible for this build failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/976
(steps 5c and 7c so failure during testimage).
I have bisected it to this change, I haven't looked into why.
Cheers,
Richard
More information about the Openembedded-core
mailing list