You are not logged in.
~6s is a lot of time... maybe its worth it. wonder if someone can post diff/patches to test such a script.
Offline
My initscripts weren't really geared towards login managers: They were geared towards console login. You can just put kdm as the first daemon and boot up very quickly. But for the people who login via console, you need to wait for EVERY daemon to load.. which is a pain.
If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. 1 Corinthians 13:2
Offline
It would be cool to apply the info from this thread to this.
Bootchart is a tool for performance analysis and visualization of the GNU/Linux boot process. Resource utilization and process information are collected during the boot process and are later rendered in an SVG or PNG encoded chart.
Offline
If the initscripts are to be rehashed to include this rather excelent idea then, please, PLEASE can support for bootsplash and fbsplash be included in the initscripts!
It is extremely frustrating to be able to set up all the bootsplash/fbsplash stuff but then be stuck becuase you can't patch the initscripts - surely catering for the users that want to use boot/fb splash is ok - it's not like it is going to massively bloat the initscripts at ALL!
Also, something that still remains and issue - if you update initscripts with the -U option then it WILL overwrite all the files - whether you have set them as to "do not remove under any circumstance" in rc.conf - if you then reinstall the old package without copying your own files back from the pacsaves they will be overwritten and you will lose them.
Should I submit bug reports/requests for this? Would i receive support - not meaning to thread hijack too much!
Offline
If the initscripts are to be rehashed to include this rather excelent idea then, please, PLEASE can support for bootsplash and fbsplash be included in the initscripts!
It is extremely frustrating to be able to set up all the bootsplash/fbsplash stuff but then be stuck becuase you can't patch the initscripts - surely catering for the users that want to use boot/fb splash is ok - it's not like it is going to massively bloat the initscripts at ALL!
Also, something that still remains and issue - if you update initscripts with the -U option then it WILL overwrite all the files - whether you have set them as to "do not remove under any circumstance" in rc.conf - if you then reinstall the old package without copying your own files back from the pacsaves they will be overwritten and you will lose them.
Should I submit bug reports/requests for this? Would i receive support - not meaning to thread hijack too much!
add
"NoUpgrade = etc/rc.sysinit" to your etc/pacman.conf file that should prevent pacman from overwriting your files.
Offline
Thanks HUM - i did that - i said i already did that - and it doesn't work - sorry PunkRockGuy
Offline
Here is a simple fastboot patch that I worked up. It allows you to specify in rc.conf which daemons to load up in the background during boot by prefixing them with an @ symbol. Note: this patch is totally separate from punkrockguy's patch, do not use both of them.
It is available here. As with punkrockguy's patch, apply it from the src directory of the initscripts package with a
patch -p1 < /path/to/bkgdDaemons.patch
Example use: my DAEMONS list in rc.conf now looks like
DAEMONS=(syslog-ng @hotplug network @netfs @sshd portmap nfslock @nfsd @acpid @crond @fam)
Warning: If you boot up into xdm/kdm/gdm and your video card requires certain kernel modules to be loaded (eg. nvidia), you may need to explicitly add those modules to the MODULES list in rc.conf if you background the hotplug daemon. This is so that the modules are loaded and initialized in time for X to start up.
Cover-My-Butt-Warning: Use this patch at your own risk. This patch messes with the scripts that boot up / shutdown your computer and as such could result in a non-booting system. Back up your init scripts before using. Make sure you have a rescue disk on hand.
Offline
Here is a simple fastboot patch that I worked up. It allows you to specify in rc.conf which daemons to load up in the background during boot by prefixing them with an @ symbol. Note: this patch is totally separate from punkrockguy's patch, do not use both of them.
It is available here. As with punkrockguy's patch, apply it from the src directory of the initscripts package with a
patch -p1 < /path/to/bkgdDaemons.patch
Example use: my DAEMONS list in rc.conf now looks like
DAEMONS=(syslog-ng @hotplug network @netfs @sshd portmap nfslock @nfsd @acpid @crond @fam)
Warning: If you boot up into xdm/kdm/gdm and your video card requires certain kernel modules to be loaded (eg. nvidia), you may need to explicitly add those modules to the MODULES list in rc.conf if you background the hotplug daemon. This is so that the modules are loaded and initialized in time for X to start up.
Cover-My-Butt-Warning: Use this patch at your own risk. This patch messes with the scripts that boot up / shutdown your computer and as such could result in a non-booting system. Back up your init scripts before using. Make sure you have a rescue disk on hand.
Sounds very nice. I tried something like this at first, but I didn't think of that simple solution. I had a DAEMONS array and a DAEMONSB array. That made things complicated. This sounds like a very good idea! Good work
If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. 1 Corinthians 13:2
Offline
I like the '@' prefix idea as well. It seems consistent with the '!' to disable a daemon.
If you develop an ear for sounds that are musical it is like developing an ego. You begin to refuse sounds that are not musical and that way cut yourself off from a good deal of experience.
- John Cage
Offline
I like the '@' prefix idea as well. It seems consistent with the '!' to disable a daemon.
i second this ... it looks very clean
The impossible missions are the only ones which succeed.
Offline
I like this idea, cause I like to know if some daemons like the network are running.
And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.
Offline
I vote for it too.
Offline
Aye, it could be better.
Offline
This is a really interesting idea. With work this could become the best startup system found in any linux distro and would serve to cancel one of the few advantages that Windows has on the desktop.
Offline
advantage? Arch boots without backgrounding in 15 seconds, can Windows ever do that *with* backgrounding?
Offline
Win Xp on my Athlon XP w/ nForce2 and software IDE drivers boots to login in about 5 sec. not counting BIOS screens.
Offline
nice. how long does arch need on your system?
Offline
Just booted up for the first time in awile, but timed it at approx 12-15 sec. not counting BIOS screens but including the kernel stuff. I should point out that the Windows install, which is now destroyed in favor of a totally Arch system, had been there for quite awhlie and the prefetching mombo-jumbo was doing it's job pretty well. I havn't tried the new background loading initscripts so that startup time is with a default Arch init loading 6-7 daemons.
I am by no means disappointed with the performance of Arch considering I don't reboot this machine now nearly as often as I did with the Windows install and so I've probably already made that boot time back 10-fold in just not having to reboot. My interest in this is that I feel that it would be cool to be more stable than Windows but also faster on the reboot . 8)
I assume that people needing an instant response from their machine on boot could just use suspend to disk and be done with it. I don't power my machine down unless I have too for some reason beyond my control.
Offline
oops, didn't notice rc.single needed to be edited too. updated patch is in same location, here.
Offline
nice patch, i'll apply it now and try it when i get home
I vote for this added into the initscripts package (email it to judd).. and I agree the prefix thing seems more arch centric to goalong with the "!" prefixing....
Offline
I also think the @ prefixing is a great idea. Perhaps this should be included with the default initscripts, but should it be enabled by default? Too bad we can't make intelligent daemon loaders that wait until the required things are loaded before trying to load one in the background (ie. fam and network).. Does this make sense?
Anywho, great work!
Offline
It's easy to have it disabled by default -- just don't put any @'s in the DAEMONS line of the vanilla rc.conf. 8)
Offline
@ it's good.
I would have made it in my patch if I'd know enough bash programming.
I don't think it is really usefull, but we loose nothing having it avaible.
I made my initscripts load in background some time ago because nfsd spend more than a minute to be [DONE], so I really felt the difference.
That would have been great to simply add an @ instead off having to modify the initscripts by myself (that would have been great for other people, not for me: i've loved to learn the simplicity of linux).
Offline
I would also like to suggest backgrounding the shared link update too... as that's the biggest hog (though it'd be better to have pacman run it after each install instead of on boot)
Offline
actually, ldconfig is already running after each pacman package install... im guessing they'd put ldconfig in the rc.sysinit to avoid the initial ldconfig execution delay on pacman execution... this makes pacman looks faster
i myself removed it toally from rc.sysinit, since pacman will execute it anyway once its needed... who needs the 20 second delay at each startup.. 8)
Offline