systemd services starting while plymouth is deactivated

[Chris Glass]

A few systemd units are started despite plymouth itself not running (nospash is set in cmdline for instance).

This results in boot times slightly longer than necessary for those systems.

[Steve Langasek (vorlon)]

Which units, adding how much time? I.e. how much hackery is it worth doing to try to stop these units from running? By all rights the only running units should be dependency scaffolding, not anything that runs an actual program.

[Chris Glass (tribaal)]

(sorry for the shallow bug report - I intended to fill it up some more but it fell through the cracks)

Specific units are:

plymouth-read-write.service
plymouth-quit.service
plymouth-quit-wait.service

Measured time spent in these: between 100 and 300ms (depending on I/O, I assume). It's a modest win for boot time, but it's also a very simple patch (https://paste.ubuntu.com/23476239/)

Despite being referenced in other services as an "after", it seems (from manually applying above patch) that other services start and normally (Before manual patch: https://paste.ubuntu.com/23479860/, after manual patch: https://paste.ubuntu.com/23479865/ , both taken on a machine with no "splash" in cmdline)

It seems like a clear cut case of removing "dead" code conditionally (switching on the cmdline presence of "splash" as for the starting service), but of course I might not have the whole picture.

I intend to try the same on a desktop machine with and without a "splash" cmdline, with FDE enabled.