Bug 7010

Does Jason's recent change to serialgetty solve such problem in another direction?

commit eddbd0c3145156559b9fe004508af6da27e379cb
Author: Jason Wessel <jason.wessel@windriver.com>
Date:   Thu Aug 29 07:00:31 2019 -0700

    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"

(In reply to comment #0)
> Created attachment 2270 [details]
> Patch to add support for creating serial-getty service files without
> enabling them
> 
> While setting up a commercial embedded system using yocto, we wanted the
> ability to start a serial-getty@.service unit when triggered with a special
> engineering-only mechanism, but not on a normal boot. We wanted the
> serial-getty@.service file to be created, but not enabled in systemd.
> Setting the SERIAL_CONSOLES line in the machine.conf to an empty string
> simply resulted in _no_ serial-getty@.service files being created. Looking
> at the systemd-serialgetty.bb file, I can see that the current do_install()
> does not have any means to specify only the bauderate of the serial port and
> not enable it by default.
> 
> I attached the solution I use. Allow the SERIAL_CONSOLES variable to be set
> to _just_ the bauderate. In systemd-serialgetty.bb, modify the sed command
> that extracts the serial port path so that it returns an empty string
> instead of the bauderate in this case, then add a simple if block to only
> enable the serial port if the serial path is not empty.
> 
> Attached patch is on top of the dizzy branch made with git format-patch.
> 
> If accepted, documentation for the SERIAL_CONSOLES would need to be updated.

Hi Joe,

Please check if Jason's patch would solve your problem in another direction.
If not, you can send out patch to oe-core mailing list.

Joe, Please comment on Jason's patch.

I unfortunately do not use Yocto on a day-to-day basis so this bug no longer affects me. Jason's patch would work for me.