Re: [gentoo-dev] Questions about SystemD and OpenRC

Il 07/08/2012 14:47, Sylvain Alain ha scritto:
> Hi everyone, for a couple of months now, I see on the list some of
> activities about OpenRC been ported to FreeBSD or OpenRC to Debian and
> other stuff related to SystemD.
>
> I have some basic questions about all that :
>
> 1. The SystemD and Udev projetcs are merged now, so what is the impact
> on the Gentoo on a short term period ?
The answer is in the hand of others, I sincerely hope someone will fork
>
> 2. I saw on some lists that Gnome/Kde and Xfce plan to use some
> SystemD API, so does it means that we will need to install SystemD
> aside of OpenRC ?
It's not possible at the moment. systemd break non-systemd setups.

>
> 3. In a long term vision, can OpenRC still exist on a Gentoo
> box(OpenRC might be able to boot the box then give the control to
> SystemD/Udev for the rest of the boot process)  or we will need to
> migrate to SystemD to be able to use Gnome/Kde or Xfce ?
PID 1 has some own properties, but systemd can work at user privileges, 
maybe
>
> 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
> related to SystemD ? I don't understand why these desktops want to
> depend on a specific Sysint....

Because starting daemons it's much more error prone than everyone 
thinks, at least everyone which didn't become involved in coding for it.

And now my personal rant with some considerations, from memory, may be 
not totally accurate.

Tried systemd (SD from now) the other day, as everyone knows it need to 
rebuild some part of the system with the "systemd" use flag.
These things broke when not started by SD, for example pulseaudio, had 
problems also with auto-mount possibly more not even noticed.

This box has 3 disk:
sda) ssd on sda for gentoo whole disk (not partitioned)
sd{b,c})  /home /srv /boot md raid 1

First problem udev/SD has is that it can't see all the file system 
labels, for some reason it only see sda and sdb so it's able to partly 
proceed in the boot sequence, mount / (root) but can't mount anything else.

After putting in fstab the real /dev paths (something really old siecle) 
manually mount them with systemctl --ignore-deps (the name of the option 
is different please bear with me) works but the dependancies are not 
satisfied, for two reasons:
a) SD does not re-calculate it's deptree/services when exiting from 
rescue shell, it still try to start the "virtual" services as fstab 
would have never modified, a reboot is needed
b) since it does not work even after reboot, there must be something 
else, but what? this bring us to the point

SD has mainly two things to debug boot `systemctl dump` and 
`systemd-journal` but the very much magnified advantages of the binary 
log^W journal are totally invisible in this case because it's 
difficult^W nearly impossible even to understand WHAT failed to start, 
not to mention WHY

the magnificient binary log^W^W journal is kept on tmpfs (in ram) so 
it's not even available at boot in different situation.

every try needed many minutes because SD wait for a long timeout before 
going to the rescue shell, gave up after few hours of try, upgrading 
Vista SP0 to current needed less reboot and time.

But this has been beneficial because I've now realized few important 
things that will be probably never disappear from SD and will be there 
forever, things that make me think this stuff is really dangerous.

List of problems that will _never_ be fixed

- SD does not see anything else than systemd for boot.
Interaction with SD from a livecd, is difficult, almost all tools don't 
work because SD is not running.
transported on remote server administration this is a *nightmare*, 
various provider offer livecd like system which don't offer SD.
so no easy migration, no easy first install, every failure is 
definitive, a no go

- the journal will never become simpler, can only grow, debugging things 
in the shell will be nearly impossible for excess of data (and lack of 
useful one if it continue this way)

- virtual/autogenerated services are and will be difficult to cope with, 
impossible to disable

- every change in the early boot procedure will require reboot

- which sum to: SD will work until it work, when something does not will 
be a royal pain to solve _and_ nothing else other than SD will be 
available to alleviate the pain

difficult to accept for the desktop, impossible for the server.

written by someone which like _some_ of the SD stuff.