On 10/06/2013 05:49 PM, Nico Kadel-Garcia wrote:
>
>
>
> On Sun, Oct 6, 2013 at 4:24 PM, Tom H <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
>     On Fri, Oct 4, 2013 at 7:53 AM, Nico Kadel-Garcia <[log in to unmask]
>     <mailto:[log in to unmask]>> wrote:
>      > On Fri, Oct 4, 2013 at 3:25 AM, James Rogers
>     <[log in to unmask] <mailto:[log in to unmask]>>
>      > wrote:
>
>
>      > We're basically going to be stuck with systemd for release 7.
>     It's wedged
>      > into all the upstream Fedora daemons, sometimes with a crowbar
>     and a can of
>      > Jiffy Lube. There are some serious problems that it resolves
>     (such as demons
>      > dying off, and requiring some sort of master daemon to make sure
>     they get
>      > restarted as needed). If you want to affect choices like that,
>     then you need
>      > to get into the developer cycles with Fedora and affect changes
>     upstream.
>
>     Given how fully-fleshed out systemd is and the momentum that it has, I
>     don't see how getting involved in Fedora or further upstream could
>     change the basic thrust of systemd.
>
>
> Oh, yes, I didn't mean to to suggest we'd have a lot of choice about
> systemd coming down the pike at *this* point.   Current Fedora releases
> have already discarded the sysvinit package, it looks like a done deal
> for the pending release 7 from our favorite upstream Linux vendor. I
> meant that if we wanted to affect changes like this, we have to be
> involved in the Fedora releases as developers, and users, and critics of
> what are the software candidates fo rthe next release.
>
>      > We could maintain two source trees, one with .spec files and init
>     scripts
>      > for systemd and the other for init scripts. I *don't* recommend
>     that, it
>      > gets nasty.
>
>     Or you could not ship a systemd file until EL-6 is retired since
>     systemd can launch and supervise sysvinit scripts.
>
>
> Our favorite upstream vendor has a nominal 10 year support cycle for
> major releases: so we're talking about 7 years from now, and a couple
> more major upstream releases to remain compatible with. I port stuff
> with daemons in it between OS releases, mostly over at
> https://gitub.com/nkadel/,and just ran into this backporting RT version
> 4.0.17 back to SL 6. (That takes about 50 new perl RPM's to port, by the
> way, that I'll try tp publish next week!) It's going to make backporting
> tools that already have systemd written into them fun.
>

Two interesting observations from a colleague who now must support a 
system using systemd --

/usr is now required to be in the boot partition because the boot 
process requires access to /usr and the executables/configuration files 
therein before the system actually is fully booted (even in the 
equivalent of single user mode)

when the system generates a diagnostic due to a condition with systemd 
(e.g., some state issue for which the issue normally should not cause a 
machine to crash/become unstable), this fills the message file and then 
crashes the system because there is no space left on the partition that 
is required by systemd

Does anyone have further experience with these features?

The analogy to Network Manager is not accurate in this case:  NM can be 
turned-off and the system will run (even the network connection can be 
manipulated by manual control, eliminating the need for NM), whereas it 
appears that this replacement for init cannot be turned off.