Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Jason Wessel <jason.wessel@windriver.com>,
	 openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist
Date: Tue, 27 Aug 2019 23:58:30 +0100	[thread overview]
Message-ID: <0f501dcaee763d8d33152fbd82af53385b8d0dc9.camel@linuxfoundation.org> (raw)
In-Reply-To: <20190821002750.52062-1-jason.wessel@windriver.com>

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@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>
> ---
>  .../systemd/systemd-serialgetty/serial-getty@.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



  reply	other threads:[~2019-08-27 22:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21  0:27 [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist Jason Wessel
2019-08-27 22:58 ` Richard Purdie [this message]
2019-08-28  0:03   ` Jason Wessel
2019-08-28  0:15     ` richard.purdie
2019-08-28 20:24       ` Jason Wessel
2019-08-28 22:24         ` richard.purdie
2019-08-28 22:41         ` Richard Purdie
2019-08-29  3:03           ` Jason Wessel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0f501dcaee763d8d33152fbd82af53385b8d0dc9.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=jason.wessel@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox