[Mageia-dev] Please test: initscripts+systemd in updates_testing

[JA Magallon]

On Sat, 29 Oct 2011 22:30:26 +0100
Colin Guthrie <mageia at colin.guthr.ie> wrote:

> 'Twas brillig, and Olav Vitters at 27/10/11 13:13 did gyre and gimble:
> > On Wed, Oct 26, 2011 at 10:27:12AM +0200, JA Magallon wrote:
> >> On Sat, 22 Oct 2011 17:07:01 +0100
> >> Colin Guthrie <mageia at colin.guthr.ie> wrote:
> >>
> >>> Hi,
> >>>
> >>> I've just pushed new initscripts+systemd packages to updates_testing.
> >>>
> >>> In the combinations I've tested:
> >>>
> >>> systemd+dracut initrd: Boot and Shutdown works fine.
> >>> sysvinit+mkinitrd initrd: Boot and Shutdown works fine.
> >>>
> >>> systemd+mkinitrd initrd: Boot fails due to not finding LVM disk.
> >>> sysvinit+dracut initrd: Boot works, shudown/restart hangs.
> >>>
> >>
> >> A couple things I noticed:
> >>
> >> - system time is bad, looks like ntpd is not started
> 
> Yeah I still need to look at that.
> 

I think that more of ntpd itself, the serious problem is that time is
not set correctly on boot. I have all my cauldron boxes bios time set
to spanish local time, and system time gets set to 2 hours earlier than
it should (GMT+1 + 1 other hour for summer time, I guess - I'll check
tomorrow sunday when we are again at winter time). And then ntpd does not
correct it.

The ntpd problem is the same that that of sshd below.

> >> - sshd is not started neither
> > 
> > had same issue with sshd
> 
> Is this not just a simple matter of enabling it? It starts fine here...
> It may not have inherited the fact it's enabled in sysvinit properly,
> but a simple "systemctl enable sshd.service" and a "systemctl start
> sshd.service" should be enough. We perhaps want to setup a sshd.socket
> file to allow on-demand loading however which is a better solution
> overall for most systems with sshd.
> 

The problem is not enabling it, but that it was enabled under sysvinit
and it does not get started under systemd after the switch. Think of
an upgrade of mageia-1 to -2 when it is done. You end without remote access
and probably others not noticed for being less critical, or others
like iptables being disabled under syscint and becoming enabled under
systemd. That is why I thought that doing that compatibility thing
between chkconfig and systemctl is a difficult mess to solve...
in some point you get out of sync. So lets go systemd at all and
kill all compatibility. Adding a dozen xxx.service that call
/etc/init.d/xxx should not be difficult. Do it once 'manually' and
forget about trying to do automagically.

And, btw, if sysvinit 'init' is killed, should it be time to move
all that /etc/init.d/xxx scripts somewhere else as systemd helpers ?

One possible solution could be...
- let systemd parse also init.d, and run what is there (as it is now)
- kill from init.d all services that have a systemd replacement
  (iptables vs iptables.service for example), and move scripts used
  by systemd .services out of init.d.
so one service is on one and only place, and you have to know which
init system (chkconfig or systemctl) handles it. When full switch is
done, init.d would be empty. 

> >> - DM service is duplicated, one is dm.service and other prefdm.service
> >>   (latest is systemd native one).
> 
> Fixed in the lastest systemd package.
> 

But why do we need both dm.service and prefdm.service ? Or
networkmanager.service and NerworkManager.service ? Let's kill all
compatibility and start getting bug reports and things fixed...

I know it is a bit hard, but IMHO its the only sane way.