missing part of the description:

... their final sum is simply inacceptable.

Hello, maybe you can try to 'debug' with bootchart:

see http://www.mail-archive.com/mageia-dev@mageia.org/msg09225.html

Hello. Thanks. I'll try that.

Same problem on 32bit systems. Booting Cauldron is terribly slow. And shutting down Cauldron is even slower. It takes ages before it decides to call SIGTERM on all remaining processes (which makes me wonder if it really asked processes to stop!).

CC: (none) => LpSolit
Hardware: x86_64 => All

what about this bug with systemd 40 ?

CC: (none) => dmorganec

(In reply to comment #5)
> what about this bug with systemd 40 ?

I see no improvement with systemd 40.

I believe, that one of the main issues is that the display manager is now waiting for services which are unnecessary for a majority of people. Entering the username and password usually takes some time and the remaining services can continue booting in the background while the user is filling the username/password.
I think I read somewhere, that dm is waiting for the network to come up, to allow the network authentication ... so ... I believe there should be a way how to conditionally skip this dependency if users are not interested in the network authentication ... this could considerably improve a perception of the boot time speed.
If such feature isn't supported directly by the systemd, then we should develop some kind of switch in the draktools changing a symlink to an alternative dm service file (without dependency on the network, etc.)

Frédéric is right with the shutdown .... there's definitely something wrong ... I have the same issue here ...

see the bug here: https://bugs.mageia.org/showdependencytree.cgi?id=2120&hide_resolved=1

That is quite a list!

When I try to reboot from Cauldron, I get returned to the login screen.  If I then select Reboot from the KDE dialog, I get what others have experienced.  Instead of going into the graphical shutdown, it stays for a long time at the text screen with the startup history.  When I decide it has frozen, it suddenly continues normally.

CC: (none) => laidlaws

(In reply to comment #4)
> Same problem on 32bit systems. Booting Cauldron is terribly slow. And shutting
> down Cauldron is even slower.

I found the culprit: Oracle Express!

If I configure it to not start the DB on boot, the boot time is 20-30 seconds faster, and shutting down is fast (10 seconds instead of 1-2 minutes).

@Jaromir:

You should install the systemd-tools package and then execute:

 systemd-analyze blame

for a textual output, or:

  systemd-analyze plot > systemd.svg

for a graphical output. You can then load systemd.svg from your web browser (e.g. Firefox) to see where and how time is wasted.

Created attachment 1755 [details]
graphical output of systemd-analyse

(In reply to comment #10)
> That is quite a list!
> 
> When I try to reboot from Cauldron, I get returned to the login screen.  If I
> then select Reboot from the KDE dialog, I get what others have experienced. 
> Instead of going into the graphical shutdown, it stays for a long time at the
> text screen with the startup history.  When I decide it has frozen, it suddenly
> continues normally.

The first sentence of this comment #10 really belongs to Bug 4605, an issue in KDE which is apparently fixed.  As for the rest, there is no longer any significant delay

Testing Mageia release 2 (Cauldron) for x86_64 Kernel 3.3.1-server-2.mga2 on a Dual-processor x86_64 , and for me the boot of mageia 2 takes a long time too.


With mageia 1 for x86_64 :

-the time for Grub to KDM is:28,20 sec
-the time for KDM to finnish start (kde4)is: 35,60 sec
-total : 63,8 sec

Now with Mageia 2 beta 2 :

-the time for Grub to KDM is:59,20 sec
-the time for KDM to finnish start (kde4)is: 62 sec
-total : 121.20 sec

Sounds a bit much time, just the double of mageia 1.

My Laptop :

ACER Travelmate 7513WSMi ,AMD Turion(tm) 64 X2 Mobile Technology TL-52 (1600MHz)
,4 Go of RAM ,GC G72M [Quadro NVS 110M/GeForce Go 7300]and hard-disk Western Digital Corp. WD3200BEKT-0 (7200 rev / min).

CC: (none) => geiger.david68210

(In reply to comment #14)
> Sounds a bit much time, just the double of mageia 1.

Can you attach the output of "systemd-analyze plot > boot.svg". You need systemd-tools package to run this command.

CC: (none) => sander.lepik

Created attachment 1942 [details]
graphical output of "systemd-analyse plot > boot.svg"

Most blame goes to mandriva-everytime.service :/ next to it is udev-settle.service.

Colin, we shoule somehow nuke this mandriva thingy :D It's causing trouble here and there :/ Not sure if there is anything to do about the udev tho'..

CC: (none) => mageia

Another option would be to add
DKMS_ONBOOT=no
HARDDRAKE_ONBOOT=no
to /etc/sysconfig/system

That would keep the netprofile selection, and /tmp cleanup.

CC: (none) => davidwhodgins

Created attachment 1946 [details]
graphical output of "systemd-analyse plot > boot.svg" for new option

(In reply to comment #18)
> Another option would be to add
> DKMS_ONBOOT=no
> HARDDRAKE_ONBOOT=no
> to /etc/sysconfig/system
> 
> That would keep the netprofile selection, and /tmp cleanup.


Ok Dave , with this options actually start going faster but still I have won only 20-25 sec.

-the time for Grub to KDM is: 35 sec
-the time for KDM to finnish start (kde4)is: 62 sec
-total : 97 sec

It is always a lot of time for starting,. And I also think that kde4 is slow (62sec instead of 37.60sec with mageia 1).

Once KDM pops up, I don't think there is anything specifically "systemd" related in terms of any speed difference - tests vs. sysvinit on current cauldron would still be interesting however.

If you think the time to KDM is still slower, please provide comparative timings on current setup (not vs. mga1) of both and also attach the output of "systemd-analyze plot >boot-analyze.svg" and "systemd-analyze blame >boot-analyze.txt"

@sander. Technically udev-settle is not 100% required on most systems. It ultimately depends on hardware. If you're hardware does not require it you can safely disable it. That said, it *is* pulled in automatically by "fedora-wait-storage.service", which is, in turn pulled in by fedora-storage-init.service and fedora-storage-init-late.service which are both a requirement of local-fs.target and thus it is effectively a requirement. Longer term we can look to enable them only when needed (i.e. when some kind of LVM is detected) rather than at all times. However it's too late in the day to go messing with this stuff I believe.

Guys. Sorry for no response for longer time.

I believe systemd is not ready for being used as primary init solution. I still get totally frozen states on different production computers and the resolution might take ages. The boot time is only a secondary issue. I'll try to get some debug data soon. I'm very sorry for delays.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

No evidence now of what I described in Comment 13

After a new fresh install for Mageia 2 with the Mageia-2-x86_64-DVD, I can
confirm that the bug is always present for me.

The workaround for now remains in Comment 18

Version: Cauldron => 2

(In reply to comment #23)
> No evidence now of what I described in Comment 13

In view of David's reply, I am running 32-bit.

This bug doesn't really serve any purpose IMO.

Harddrake takes time. That can and is being optimised but it's not something that will be fixed in mga2 and work on it in cauldron is simply part of the normal process and I don't think the primary maintainer is on this bug anyway.

Some time killers (like mandriva-clean-var-run-lock.service) have already been nuked in Cauldron.

So unless someone still has some specific problems directly related to systemd, I'll just close this bug. Feel free to reopen if you have a valid test case.

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME

(In reply to comment #26)
> Some time killers (like mandriva-clean-var-run-lock.service) have already been
> nuked in Cauldron.

What about mandriva-everytime.service? It eats 19 seconds.

As I said, above harddrake takes time to run and that's nothing to do with systemd. It is being optimized and if checking for new hardware on every boot is not needed it can be configured not to run this way as noted in comment 18.

Longer term I'd like to see the catch all "mandriva-everytime.service" split up into several smaller units instead which would make it more obvious and easier to disable different bits without tweaking a mysterious sysconfig file, but again I don't think this bug properly represents any of these general changes.