[systemd-devel] Check for plymouth (e1b2b49465615727a2c3883d06d1b9ff339aec67)
lennart at poettering.net
Sun Feb 13 13:22:33 PST 2011
On Thu, 10.02.11 07:02, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
> --- a/units/plymouth-start.service
> +++ b/units/plymouth-start.service
> @@ -12,7 +12,13 @@ Wants=systemd-ask-password-plymouth.path
> After=systemd-vconsole-setup.service udev-settle.service
> +# Dracut informs us with this flag file if plymouth is already running
> ExecStart=/sbin/plymouthd --mode=boot
> ExecStartPost=-/bin/plymouth --show-splash
> And what other poor folks who do not happen to use dracut should do?
Nothing. At this time consider this an optimization for dracut
systems. If you are not using dracut then plymouthd will simply fail if
started in case an instance is already running. And this error is then
ignored so everything is behaving as it should.
We added this flag file mostly to make it unnecessary to spawn plymouth
Also note that as soon as the following bug is fixed the generation of
this flag file will move to plymouth and can then be dropped from dracut:
Also, nothing stops your from creating this flag file in your initrd
implmentation of choice.
And last but most importantly: We strongly encourage all distros to
adopt dracut as initrd implementation. There's no hard dependency from
systemd to dracut, but if you use dracut you will get a number of
features you otherwise will miss. In addition to the plymouth
optimization above this is for example that profiling info is passed
from dracut to systemd and information about fsck-on-root-from-initrd.
There's very little point in every distro maintaining their own initrd
implementation. Dracut appears to us to be the best implementation in
existance and Harald is very open to cooperation with other distros and
hence we try to gently push everbody to adopt initrd in their
distros. And let me make explicitly clear that we use this "weak
dependency" between systemd and dracut as a means to achieve that.
In summary: if you use an initrd, make it dracut. If you do you get the
best integration with systemd. Other initrd's will work too, but things
won't be as powerful.
> I would really prefer to see generic ConditionCommandStatus and simply
Well, we do this all to make it unnecessary to spawn off one more
process. Doing ConditionCommandStatus= would necessarily spawn one more.
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel