Re: Replacing rc(8) (Was: FreeBSD Boot Times)
separate and optional program. that's acceptable, except i have no idea why this fscadm enable/disable. editing config is enough. I don't think I understand i have no idea why this fscadm enable/disable. editing config is enough. and would ask you elaborate for me. Thanks, why adding solaris style command to add a line in text file. just edit a text file. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Jun 22, 2012 7:33 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: separate and optional program. that's acceptable, except i have no idea why this fscadm enable/disable. editing config is enough. I don't think I understand i have no idea why this fscadm enable/disable. editing config is enough. and would ask you elaborate for me. Thanks, why adding solaris style command to add a line in text file. just edit a text file. Scripting? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
why adding solaris style command to add a line in text file. just edit a text file. Scripting? echo newserviceline file grep -v servicetoberemoved file file.new;mv file.new file ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Fri, 22 Jun 2012 09:02:44 +0200 (CEST) Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: why adding solaris style command to add a line in text file. just edit a text file. Scripting? echo newserviceline file grep -v servicetoberemoved file file.new;mv file.new file Why have people edit yet another file to do process monitoring, and have them kill hup a service just to have it work? Not very optimal I thought. -- Tom Rhodes ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. ... and to be able to switch between two configurations at runtime, without taking down services listed active in both configurations preferably. i already proposed how to make this easily with single rc.conf only. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other true. can be actually added easily. - monitor running services and restart them if they crash should not be done, or at least not default. Compared to all the init/RC systems on Linux, ours has *many* advantages, not the least of which are: - very simple text configuration file it's a requirement not just adventage :) Yes. I don't even think it *needs* improving, but service profiles including network profiles would be really nice and worth looking into. If we can get that without loosing the simple text-file-based configuration, the better. we can. but from what i've seen about openrc it is overly complicated. For sure better that other things used in linux distros but still not tolerable. why replace something very good? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
ifconfig_em0=inet ... ( default (or unknown) runlevel ) ifconfig_em0_foolevel=inet ... ( foolevel runlevel ) ifconfig_em0_maintenance=inet ... ( maintanence runlevel ) too ? well - possible BUT... but well. this will not require only changing launcher script for rc.d/* things but scripts itself. and extra flag so launcher at runlevel change will have to rerun network initialization script. Can you give an example where you need that? it is a bit strange, network IP numbers are the same no matter what we do at present. i will think about it, not doing it but allowing to easy make it then. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 21.06.2012, 12:22 Uhr, schrieb Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. Nicely thought. Count me in for testing. Do you think it would be possible to have something along the lines of ifconfig_em0=inet ... ( default (or unknown) runlevel ) ifconfig_em0_foolevel=inet ... ( foolevel runlevel ) ifconfig_em0_maintenance=inet ... ( maintanence runlevel ) too ? Michael ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 21.06.2012, 12:56 Uhr, schrieb Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: ifconfig_em0=inet ... ( default (or unknown) runlevel ) ifconfig_em0_foolevel=inet ... ( foolevel runlevel ) ifconfig_em0_maintenance=inet ... ( maintanence runlevel ) too ? well - possible BUT... but well. this will not require only changing launcher script for rc.d/* things but scripts itself. and extra flag so launcher at runlevel change will have to rerun network initialization script. Can you give an example where you need that? it is a bit strange, network IP numbers are the same no matter what we do at present. I thought that network would be more complicated. My use case: I maintain a business application consisting of - FreeBSD - several ports - my software and I run this system: a) for development, in a VM on my laptop on my local network; b) for demonstration and customer guided planning, in a VM on my laptop on the customers network, c) for production, on a machine on the customers network, d) for production, in a VM on the laptops of the customers team. The software is the same for all 4, but they differ in services started and in network settings. Having service profiles and network profiles would allow me to have a convenient method of delegating the whole setup to the application: System boots, no services default network, application starts, detects machine role (devel, demo, server, portable), configures the network and starts the appropriate services. As in: I have a configuration file for the application anyway. This configuration file contains the machine role (devel, demo ...) anyway. If I could send this role as a parameter to rc mode role and network and services would be configured accordingly, I could have an identical rc.conf over all roles, and I'd consider that a big plus. Michael ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Jun 20, 2012 11:03 PM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: scripts, i deleted most of it and put startup sequence in single file. It was plain horror. You would weep if you saw Solaris's SMF, then. Everything is i don't really know what i've seen. i've installed latest solaris demo downloaded from oracle. After nearly an hour of installation over which i had really no control and no real clue what's going on i finally after over 5 minutes got the system booted, logged as root and tried to understand the /etc tree, boot process and gave up really quickly. just seeing a files and directories (both numerous) of just a kernel binaries was truly enough. Now... lets go back to FreeBSD which is controllable and understandable by a human. Your arrogance is astounding. Did you read man hier? Unfamiliarity does not make it incomprehensible. Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 2012-Jun-18 19:18:57 -0400, Brandon Falk bfalk_...@brandonfa.lk wrote: As the original poster of this thread, I can also say that Doug is correct. The issue is not rc, it is the actual kernel boot process. I've videoed my netbook rebooting and gone through the video in slow motion and that definitely doesn't match what I see. When it comes to a desktop/laptop/simple server and all you do with rc is configure a static IP, start dbus/hal/sshd, and maybe launch a few jails... at least 90-98% of the boot process is spent doing the kernel work. In my case, starting from when the screen blanks after a reboot, the breakdown is: 7.4s - POST + BIOS splash (including ~1s waiting for input) 4.4s - boot0/1/2, starting loader (including boot spinners) 1.5s - loading kernel 11.0s - loader countdown 7.0s - kernel startup 32.0s - rc scripts (mounting root through VTY login prompt) 5.0s - X + xdm startup Note that the majority of kernel probe time is: 2000ms - atkbd 750ms - ata 500ms - memory probe 500ms - ath0 450ms - psm0 So, in my case, rc scripts account for just under 50% of the total boot time and 50% of the remainder are various waiting for input timeouts. The kernel amounts for 10% of the total time and 50% of that is 4 devices. I intend to work through the rc process in more detail to see where I can reduce the elapsed time. -- Peter Jeremy pgpfk36pZhHvM.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, 21 Jun 2012 17:10:06 +0200 Daniel Gerzo dan...@rulez.sk wrote: Hello, Just picking a random message related to this issue. Maybe Tom might update us a bit with the status of his project ;-) Oh, put me on the spot, thanks Daniel! :) Citát Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: - monitor running services and restart them if they crash should not be done, or at least not default. http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control So, I'm not following the -hackers list (too much email, too little personal time); however, I did take a few moments to familarize myself with the conversation. First off, my project was an attempt to pull what I liked from SMF without some of the annoying parts. I hadn't found it overly complicated, but very SYSV like (for very obvious reasons). At point, I wondered how interesting it would be to replace rc or augment it in some way that we could have several of the very interesting ideas that are floating around out there. Like parallel start up, control of base and ports rc, control of inetd and xinet services, and a quick way to get their status. But it was a passing interest that, without some additional hands, will never turn into a real project. Though, my services control stuff is in the ports collection now (see sysutils/fsc) but that is a post-startup mechanism. Sorry I don't really have more to contribute right now, thanks, -- Tom Rhodes ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Hello, Just picking a random message related to this issue. Maybe Tom might update us a bit with the status of his project ;-) Citát Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: - monitor running services and restart them if they crash should not be done, or at least not default. http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control -- S pozdravom / Best regards Daniel Gerzo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote: Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. Sorry but I completely disagree here. Why ? Because do one thing and do one thing well. What do you mean ? service_enable=YES - enables the service ... IT IS NOT TO ALSO ADD MORE CRAP TO. Try something like the following... service_runlevels=1 2 3 4 5 And provide a way to say... allservice_runlevels=3 4 5 which would basically state that every service runs under runlevel 3,4,5 unless specifically stated. Lets not bastardize this overly simple process by modifying already existing variables. Add a framework to coexist and teach rc to respect and comply with it. current rc scripts would not have to be modified if done correctly as well. You can short circuit the _enable= vars early on by just inspecting its _runlevel= var... Same thing could be had for a service profile script. nothing in etc/rc.d/ would have to be modified. -- - (2^(N-1)) pgpAPKdQ8kFpq.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Try something like the following... service_runlevels=1 2 3 4 5 And provide a way to say... Well - i agree with you. just invent a syntax to define service runlevels as all except ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Jun 21, 2012 5:15 PM, Jason Hellenthal jhellent...@dataix.net wrote: On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote: Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. Sorry but I completely disagree here. Why ? Because do one thing and do one thing well. What do you mean ? He means the UNIX philosophy. http://www.faqs.org/docs/artu/ch01s06.html Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
should not be done, or at least not default. http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control separate and optional program. that's acceptable, except i have no idea why this fscadm enable/disable. editing config is enough. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 21, 2012 at 05:19:27PM +0100, Chris Rees wrote: On Jun 21, 2012 5:15 PM, Jason Hellenthal jhellent...@dataix.net wrote: On Thu, Jun 21, 2012 at 12:22:08PM +0200, Wojciech Puchar wrote: Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. Sorry but I completely disagree here. Why ? Because do one thing and do one thing well. What do you mean ? He means the UNIX philosophy. http://www.faqs.org/docs/artu/ch01s06.html Thanks.. I didn't have a link at hand for that. -- - (2^(N-1)) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/21/2012 05:28 AM, Peter Jeremy wrote: 32.0s - rc scripts (mounting root through VTY login prompt) I think that there is some confusion about what I wrote originally, so let me clarify. From the time that /etc/rc starts through the time that the prompt appears almost all of the time is spent waiting for the services to start. There is very little time spent IN the rc scripts themselves (barring something that is poorly written of course). It's also worth noting that because the time spent in this phase is heavily dependent on what services you're starting, different people are going to have vastly different experiences. So the only way to improve the time from /etc/rc to usable system (whatever that means for the user) is to see what we can parallelize. The problem is that this is a really hard problem. :) And as someone pointed out, changing from a serial to a parallel process is going to be disruptive because it will uncover the inadequately specified dependencies that we have now which are hidden by the serial process ... and that's just the base. The over 800 rc.d scripts in the ports are (sadly) more wrong than right when it comes to specifying their rcorder stuff. This is mostly a holdover from the old days when the local scripts were all run in the same spot regardless of what was in PROVIDE/REQUIRE. Ever since I brought the local scripts into the overall rcorder (over 6 years ago now) we've been refining this, but dealing with this issue has to be something that is carefully considered in the planning for any proposed modifications. Personally, if we were going to undergo the amount of work it would take to handle parallelization of the existing rc.d framework; I'd rather put that work into designing and building a better system that does other things we need in addition to booting faster. To that end I like the direction that the thread is going in terms of discussing what a new system should have. I have some thoughts about that, but I'd like to let others talk for a while first. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, 21 Jun 2012 12:22:08 +0200 (CEST) Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. With a couple of additions: - it should be easy to see which services are on at a given runlevel. - it should be easy to see which runlevels a service is on at. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) Using two symbols to indicate negation - one to start, and then one on each runlevel - is overkill. There's not a use case where you have a keyword YES or ALL and then runlevels that you start. Personally, I'd restrict YES/NO/ALL to being single symbols, and use NOT runlevels to mean All but these. A bare NOT should get the same treatment as a YES/NO/ALL with text after it. name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. But each line has become more complicated, going from a simple on/off setting to a small language that can even have errors (like foolevel -barlevel). This violates the second thing on your list of things we don't want to change. Further, while you can easily tell what runlevels a service is on at, you can't easily tell what services are on at a given runlevel - that begs for a tool to be written. If you instead violate the requirement that we stick with a single rc.conf, the conf files can continue to have the same contents. For instance, create rc.conf.d/runlevel. If rc.conf exists, we just ignore the directory. Otherwise, use rc.conf/runlevel. Or maybe rc.conf gets is a link to rc.conf/default. The downside is that it adding a service now becomes harder - you have to edit each runlevel script instead of just one. This also begs for a tool to be written. Given the choice between having a file that wants a tool for reading, or one that wants a tool for writing, I'll take the latter. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. That's also true for my proposal. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
1) runlevels with arbitrary names. runlevel change would start and stop right services. With a couple of additions: - it should be easy to see which services are on at a given runlevel. already proposed in rc.conf - it should be easy to see which runlevels a service is on at. same. service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) Using two symbols to indicate negation - one to start, and then one on each runlevel - is overkill. There's not a use case where you have a better method already proposed by jhellent...@dataix.net But each line has become more complicated, going from a simple on/off setting to a small language that can even have errors (like foolevel -barlevel). This violates the second thing on your list of things we see above. The downside is that it adding a service now becomes harder - you have to edit each runlevel script instead of just one. i unable to understand this sentence. rc.d scripts would be exactly as they currently are. extra data in rc.conf would define runlevels at which they are active. doing this as currently (_enable=YES) would mean every runlevel. my point is that if you put new startup system in place of old, nothing will change with your existing rc.conf! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, 21 Jun 2012 20:01:41 +0200 (CEST) Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: 1) runlevels with arbitrary names. runlevel change would start and stop right services. With a couple of additions: - it should be easy to see which services are on at a given runlevel. already proposed in rc.conf - it should be easy to see which runlevels a service is on at. same. No, harder. The downside is that it adding a service now becomes harder - you have to edit each runlevel script instead of just one. i unable to understand this sentence. rc.d scripts would be exactly as they currently are. Because you're taking it out of context. You removed the counter proposal above it. extra data in rc.conf would define runlevels at which they are active. doing this as currently (_enable=YES) would mean every runlevel. Not in the counter proposal. my point is that if you put new startup system in place of old, nothing will change with your existing rc.conf! Also true in the counter proposal. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
z my point is that if you put new startup system in place of old, nothing will change with your existing rc.conf! Also true in the counter proposal. so i miss something about the counterproposal. please point me out ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 21, 2012 at 5:13 AM, Chris Rees utis...@gmail.com wrote: Your arrogance is astounding. Did you read man hier? Unfamiliarity does not make it incomprehensible. There's more going on than just unfamiliarity. Earlier versions were unfamiliar to someone used to Linux or BSD, but easy to understand because they were mostly configured by flat files. Modern Solaris has deliberately moved away from this and toward opaque configuration tools that modify stuff you aren't supposed to touch, behind the scenes. It's a bit like Windows that way; it's made it easier to manage if you're doing something pre-configured (like starting/stopping an existing service), but if you want to do something custom you have to do a *lot* of digging to figure out how to make it work. Some of the new stuff (like NWAM network configuration) is not even configurable without a GUI. -- David Brodbeck System Administrator, Linguistics University of Washington ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
manage if you're doing something pre-configured (like starting/stopping an existing service), but if you want to do something custom you have to do a *lot* of digging to figure out how to make it work. Some of the new stuff (like NWAM network configuration) is not even configurable without a GUI. Fortunately FreeBSD is not solaris so we shouldn't care about how solaris do this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 2012-Jun-21 10:09:01 -0700, Doug Barton do...@freebsd.org wrote: On 06/21/2012 05:28 AM, Peter Jeremy wrote: 32.0s - rc scripts (mounting root through VTY login prompt) I think that there is some confusion about what I wrote originally, so let me clarify. From the time that /etc/rc starts through the time that the prompt appears almost all of the time is spent waiting for the services to start. There is very little time spent IN the rc scripts themselves (barring something that is poorly written of course). Agreed - I (and I expect everyone else) am using rc script to cover the total wall time between exec()ing the script and it returning - in most cases, this is almost entirely synchronous service startup time. The end-user experience is governed by how long does it take between rebooting or turning the power on and when I can login or interact with my service. Reducing this total time is going to require a combination of changes in multiple areas. One point I'd make is that the rc scripts run with cold caches so reads cause physical I/O. There are somewhat over 150 scripts in /etc/rc.d and a variable number in /usr/local/etc/rc.d (I have between 6 33 on different systems). rcorder(8) needs to read each script so, on a system using spinning rust, this amounts to 2-3 seconds overhead. So the only way to improve the time from /etc/rc to usable system (whatever that means for the user) is to see what we can parallelize. The problem is that this is a really hard problem. :) And as someone pointed out, changing from a serial to a parallel process is going to be disruptive because it will uncover the inadequately specified dependencies that we have now which are hidden by the serial process ... (I mentioned this problem). One (though intrusive) way would be to use the approach the ports system used when it enabled parallelism within port builds: Add new keyword(s) within each script to control parallelism for that script. Initially, the infrastructure would assume serial unless scripts were explicitly marked parallel or background but once the situation was sufficiently under control, it could be flipped to assume parallel unless a script specifically specified serial. (Note that I haven't looked at the detail of actually implementing this). As an aside, usable system is a relevant point. My Netbook originally came with Linpus and it took about 30s from poweron until the Linpus GUI was displayed and allowed user interaction. This looked quite impressive but it took another 30-60s before the system was actually usable because the GUI was started quite early before (eg) the network was up. -- Peter Jeremy pgpXRyu725r3y.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote: There's no need to do a wholesale replacement of the RC system in FreeBSD to support this concept. What you are describing are service profiles. And we already have a single file that describes the default service profile for FreeBSD: /etc/rc.conf. That lists every service that should be started (or stopped). All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other - monitor running services and restart them if they crash - Service dependencies: if a service fails that is required by another service, the other is stopped as well. - Monitoring services and ability to configure the service supervisor behaviour: if service fails and is restarted X times in period Y, execute action Z. - Extending the concept of service beyond userland. Kernel services are services too, if eg. network is down, you probably don't want to even try to start a dozen jails. - Permission control (like possible in jails now, limited root), non-root users can be delegated permissions to start/stop selected services and configure their behaviour. It's clearly arguable as to which of these features and to what extent is reasonable to implement and whether or not it can or should be done in the existing rc system, instead of implementing a new one that just supports the old rc system as it is. There are real benefits in some of these features, but they can easily turn out as esoteric features in a bloated piece of code, if not implemented with great care. I don't know the internals of current rc system well enough to form educated opinion on how any of this could be done in practice, but I have plentyful experience in how and why projects fail and in this particular case I see a lot of chances for fail with relatively little gain. Just something to think about.. Might be worth noting that I work with Linux systems most of the time and over-engineering is a chronic problem there. I've always admired the simple but effective BSD approach, rather do less but well than a lot badly. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 2012-Jun-21 00:17:11 +0200, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: - Lack of dependency handling for manual start/stop which is not really a problem and often an adventage. In your opinion. IMO, runlevels are a mostly a work-around to hide the lack of proper dependency handling. One obvious use for dependencies is where I have an occasional need for a box to be a NFS server. Given proper dependency handling, I can say service nfsserver onestart and it will automatically start rpcbind, statd, lockd and mountd. Another case is doing single-user maintenance on a ZFS system. It would be nice to be able to just say service zfs start instead of having to remember to start hostname and hostid first. I agree there are cases where you might want to ignore dependencies. This is easily handled with at ignore dependencies flag on service. - No provision to automatically restart a daemon if it dies. but it should not be a part of rc subsystem at all. Both the monitoring tool and rc subsystem have to interwork to ensure that services aren't inappropriately started or stopped. You can treat them as separate if you insist but the interactions make it much easier if they are designed together. First - deamons should not die without reason. Agreed but sometimes they can for a wide variety of reasons. If they do, admin should clearly know it Agreed. But this still requires infrastructure that is not currently avaliable in the base system and is irrelevant to the issue of whether the daemon should be restarted automatically. and feel it's effects, Some of this can be automated. And a fallback of try starting it a few times and complain loudly if that doesn't work is easily implemented (init(8) does it now) and generally works. and after fixing a source problem , restart it manually. This can present difficulties if you can't actually login remotely because it's sshd that has aborted unexpectedly. And it can be irritating when you get woken at 0300 just to restart some random service that glitched. in case when you are for some reason required (temporarily of course) to use daemons that often dies, then just make restart wrapper shell script and put it in place of actual daemon in rc.d script. It's nothing to do with often dies. Unless you have bug-free sotfware, you can have rarely-and-unexpectedly dies - which is just as annoying if it occurs when you (or a customer) needs it. And, with this approach, you wind up with N protected daemons and a further N (or 2N if you're paranoid) monitoring daemons - each thrown together independently. A single, central process that can detect when a process dies (or fails some pre-defined working normally test) and optionally take some pre-defined action would seem preferable. (Hint: init(8) can already do a lot of this). there is IMHO already too much automata in default FreeBSD: default /etc/crontab, /etc/newsyslog.conf and /etc/periodic directory. All gets deleted by me as soon as i install FreeBSD. You are free to disable or delete as much of FreeBSD as you like but I personally prefer my systems to reduce my workload by automating normal maintenance tasks. -- Peter Jeremy pgp749EyaVr0n.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/21/2012 06:49 PM, Atte Peltomäki wrote: On Wed, Jun 20, 2012 at 02:42:49PM -0700, Freddie Cash wrote: There's no need to do a wholesale replacement of the RC system in FreeBSD to support this concept. What you are describing are service profiles. And we already have a single file that describes the default service profile for FreeBSD: /etc/rc.conf. That lists every service that should be started (or stopped). All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other OpenRC does this. - monitor running services and restart them if they crash OpenRC does not do monitoring, but it has the prerequisites in place necessary to implement that. It will tell you which services crashed if you run `rc-status`. It should be possible to implement daemon-tools-like monitoring. - Service dependencies: if a service fails that is required by another service, the other is stopped as well. It is possible to implement this in OpenRC. - Monitoring services and ability to configure the service supervisor behaviour: if service fails and is restarted X times in period Y, execute action Z. This is also possible to implement, although it would be a pain. - Extending the concept of service beyond userland. Kernel services are services too, if eg. network is down, you probably don't want to even try to start a dozen jails. OpenRC does this. - Permission control (like possible in jails now, limited root), non-root users can be delegated permissions to start/stop selected services and configure their behaviour. This description is too vague for me to be able to comment on it. It's clearly arguable as to which of these features and to what extent is reasonable to implement and whether or not it can or should be done in the existing rc system, instead of implementing a new one that just supports the old rc system as it is. There are real benefits in some of these features, but they can easily turn out as esoteric features in a bloated piece of code, if not implemented with great care. I don't know the internals of current rc system well enough to form educated opinion on how any of this could be done in practice, but I have plentyful experience in how and why projects fail and in this particular case I see a lot of chances for fail with relatively little gain. Just something to think about.. Might be worth noting that I work with Linux systems most of the time and over-engineering is a chronic problem there. I've always admired the simple but effective BSD approach, rather do less but well than a lot badly. OpenRC is about 10,000 lines of code and is a mix of C and POSIX shell. Performance critical code is written in C. Debian's sysvinit is 3,000 lines of bash. POSIX shell is more verbose than bash and C is even more verbose than POSIX shell, but I would consider it to be fairly lean. If I recall correctly, I was told that Upstart is 80,000 lines of code and systemd is roughly 200,000 lines of code. If you consider of all of systemd's dependencies, it becomes 2,000,000 lines of code. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, 21 Jun 2012 18:20:44 +0200 (CEST) Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: should not be done, or at least not default. http://www.freebsd.org/news/status/report-2010-10-2010-12.html#FreeBSD-Services-Control-(fsc) http://www.freebsd.org/news/status/report-2012-01-2012-03.html#FreeBSD-Services-Control separate and optional program. that's acceptable, except i have no idea why this fscadm enable/disable. editing config is enough. I don't think I understand i have no idea why this fscadm enable/disable. editing config is enough. and would ask you elaborate for me. Thanks, -- Tom Rhodes ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Jun 20, 2012, at 12:45 AM, Doug Barton wrote: I was working on a reply along similar lines, but instead I'll say that i agree 100% with what Mark said, and thanks to him for saving me a lot of time. :) Richard, with all that said if you still are interested in specs for a test program, I'm still willing to help with that. Just let me know. I agree with both Mark and Doug. For the record, my point wasn't to discourage anyone from proposing ideas or to do good work. If the change is beneficial and helps make folks' lives easier, I'm sure at least one person will welcome the change with open arms in FreeBSD proper. Thanks, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Mon, Jun 18, 2012 at 03:53:26PM -0700, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. Improving boot times can be done in two ways: 1) Implement proper service dependency handling framework 2) Implement ad-hoc service dependencies Second choice is obviously not kosher for all things BSD. *if* the first choice can be implemented into existing rc with reasonable amount of work and non-intrusively, it could be a viable approach. Otherwise it would make more sense to go ahead and implement a real improvement over existing system. In my view, this is a similar issue to what UFS2 had; rather breathe some life into old system without taking much risks and have ZFS take over later as a real improvement. In any case, improving boot times is the very least significant benefit from implementing service dependencies, especially for an OS such as FreeBSD which isn't meant to be rebooted except during OS upgrade. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 10:59 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Mon, Jun 18, 2012 at 03:53:26PM -0700, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. Improving boot times can be done in two ways: 1) Implement proper service dependency handling framework 2) Implement ad-hoc service dependencies Second choice is obviously not kosher for all things BSD. *if* the first choice can be implemented into existing rc with reasonable amount of work and non-intrusively, it could be a viable approach. Otherwise it would make more sense to go ahead and implement a real improvement over existing system. In my view, this is a similar issue to what UFS2 had; rather breathe some life into old system without taking much risks and have ZFS take over later as a real improvement. In any case, improving boot times is the very least significant benefit from implementing service dependencies, especially for an OS such as FreeBSD which isn't meant to be rebooted except during OS upgrade. Sorry, but as it's been said in this list, there are several use patterns for FreeBSD. I use it in both a laptop and a PC and I boot them every time I want to use them. Believe it or not I don't like let them consuming energy and making noise during night, specially the laptop :) So please, let's assume FreeBSD has to be (re)booted from time to time and not only for OS upgrades or when it crashes. Also, in embedded systems, boot time is an important factor. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Improving boot times can be done in two ways: 1) Implement proper service dependency handling framework 2) Implement ad-hoc service dependencies ZERO) Speed up kernel startup With custom kernel containing only needed devices it is still a bit long. rc.d/* things take trivial amount of time compared to kernel! Anyway -1) don't care in most cases. FreeBSD is rarely rebooted. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 11:36 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Improving boot times can be done in two ways: 1) Implement proper service dependency handling framework 2) Implement ad-hoc service dependencies ZERO) Speed up kernel startup With custom kernel containing only needed devices it is still a bit long. rc.d/* things take trivial amount of time compared to kernel! Anyway -1) don't care in most cases. FreeBSD is rarely rebooted. While you may not care, please bear in mind that there are users who do care. Personally I think that the kernel boot time is the killer here and the work should go there and second on the rc system. PS: nothing wrong in having an OS that boots faster, performs better is more stable than others :). This is something I would like to see as an improvement. Wouldn't you ? -- Best regards, Claudiu Vasadi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Personally I think that the kernel boot time is the killer here and the work should go there and second on the rc system. exactly what i wrote. rc.d subsystem is quick, and anyway in special cases just delete in and write all needed startup in /etc/rc i assume it is embedded system - in which boot time is very important. PS: nothing wrong in having an OS that boots faster, performs better is more stable than others :). This is something I would like to see as an improvement. Wouldn't you ? of course i do! Do you have USB in that system? Compile whole USB as module. put kldload statement in /etc/rc that way (example): /sbin/kldload /boot/kernel/uhci.ko USB takes long in kernel, but now it will go in background while the rest initializes. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote: That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? We want you to do the work to prove that it is an improvement. Otherwise it's just another claim. You seem to be missing a couple of principles here, the most important of which is first, do no harm. FreeBSD has as one of its underlying principles not to violate POLA (Principle Of Least Astonishment.) The corollary is that we don't replace code unless we're convinced (not just told) that the replacement is a better solution. If this makes FreeBSD more conservative than the way other OSes do things, so be it. I'm not trying to be harsh here. What I'm saying is that the burden of proof is on the person making the claims it's better to demonstrate that it's so. Otherwise, there are a zillion PRs with patches already in the database for committers to pick up and work on. I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. Then I expect the situation to remain unchanged. fwiw, from previous discussions on FreeBSD boot time, ISTR that there are other places where more time is spent. Some analysis to prove that indeed the rc subsystem is the dominant term would be a good starting place. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
I was working on a reply along similar lines, but instead I'll say that i agree 100% with what Mark said, and thanks to him for saving me a lot of time. :) Richard, with all that said if you still are interested in specs for a test program, I'm still willing to help with that. Just let me know. Doug On 06/20/2012 12:39 AM, Mark Linimon wrote: On Tue, Jun 19, 2012 at 06:45:13PM -0400, Richard Yao wrote: That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? We want you to do the work to prove that it is an improvement. Otherwise it's just another claim. You seem to be missing a couple of principles here, the most important of which is first, do no harm. FreeBSD has as one of its underlying principles not to violate POLA (Principle Of Least Astonishment.) The corollary is that we don't replace code unless we're convinced (not just told) that the replacement is a better solution. If this makes FreeBSD more conservative than the way other OSes do things, so be it. I'm not trying to be harsh here. What I'm saying is that the burden of proof is on the person making the claims it's better to demonstrate that it's so. Otherwise, there are a zillion PRs with patches already in the database for committers to pick up and work on. I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. Then I expect the situation to remain unchanged. fwiw, from previous discussions on FreeBSD boot time, ISTR that there are other places where more time is spent. Some analysis to prove that indeed the rc subsystem is the dominant term would be a good starting place. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
The problem is deeper, I'm using minimalized kernel without USB and greatest hang is 3 or so seconds after Timecounters tick every 1.000 msec just before ada0 appears. And I have already tried modularized ada - results are the same. Did you tried to add printk within freebsd kernel now and then to find out where exactly that wait happen? On my laptop no such delay near that place happens. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Wojciech Puchar wrote: Personally I think that the kernel boot time is the killer here and the work should go there and second on the rc system. exactly what i wrote. rc.d subsystem is quick, and anyway in special cases just delete in and write all needed startup in /etc/rc i assume it is embedded system - in which boot time is very important. PS: nothing wrong in having an OS that boots faster, performs better is more stable than others :). This is something I would like to see as an improvement. Wouldn't you ? of course i do! Do you have USB in that system? The problem is deeper, I'm using minimalized kernel without USB and greatest hang is 3 or so seconds after Timecounters tick every 1.000 msec just before ada0 appears. And I have already tried modularized ada - results are the same. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Mark Linimon wrote: fwiw, from previous discussions on FreeBSD boot time, ISTR that there are other places where more time is spent. Some analysis to prove that indeed the rc subsystem is the dominant term would be a good starting place. While I don't want to proliferate this thread or advocate any kind of change, I want to address the sentiment that time spent in rc during boot is small or insignificant relative to the kernel time. The last time concurrent rc patches where proposed I measured boot time on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from power on to login prompt, 20-25 where spent in rc, and parallel execution of it shaved off 7 seconds from boot time. I'm also seeing similar breakdown on VirtualBox: rc subsystem consistently takes about 40-50% of boot time. This is on a system with a static IP and where only sshd is started (even sendmail is disabled). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, 20 Jun 2012 04:27:09 -0500, Fernando Apesteguía fernando.apesteg...@gmail.com wrote: Also, in embedded systems, boot time is an important factor. If you're designing a very specific embedded product based on FreeBSD why aren't you writing your own startup system? Why would anyone expect a general purpose out of the box OS to excel in a highly optimized embedded environment? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/20/2012 03:39 AM, Mark Linimon wrote: fwiw, from previous discussions on FreeBSD boot time, ISTR that there are other places where more time is spent. Some analysis to prove that indeed the rc subsystem is the dominant term would be a good starting place. I neither claimed that it was dominant nor should that be a prerequisite for improvements to be made. The start time of FreeBSD jails in particular would benefit most from RC improvements. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
The last time concurrent rc patches where proposed I measured boot time on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from power on to login prompt, 20-25 where spent in rc, and parallel execution of it shaved off 7 seconds from boot time. I'm also seeing similar breakdown on VirtualBox: rc subsystem consistently takes about 40-50% of boot time. This is on a system with a static IP and where only sshd is started (even sendmail is disabled). strange but with static IP it takes maybe 3 seconds without any modifications. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Also, in embedded systems, boot time is an important factor. If you're designing a very specific embedded product based on FreeBSD why aren't you writing your own startup system? Why would anyone expect a general what i not only already proposed, but did myself doing my own FreeBSD set for X11 terminal that had to fit in 128MB flash (or use NFS, but flash is there already :) and as fast as possible run Xorg -query i removed most of /etc, and put everything in /etc/rc. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Hi all, I wanted to jump in here. My name is Daniel Robbins and I'm the creator of Gentoo Linux and the original designer of the Gentoo initscripts, which now exist in rewritten form as OpenRC. FreeBSD inspired many of the concepts in Gentoo Linux. I see a great potential for collaboration here between Gentoo, Funtoo (my current project, a derivative/fork of Gentoo), FreeBSD and OpenRC (which is now an independently-managed project, distinct from the upstream distros) stripped list of CC recipient - got too large. There has been some suggestion of a boot-time shoot-out, and it makes perfect sense to me that the OpenRC team would need to demonstrate the benefits of OpenRC first, before FreeBSD devs devote time to looking at OpenRC. Whatever benefits are, and for sure they are think of this: 1) can it be compatible with 2 ports already made for FreeBSD, where many of them install rc.d scripts in CURRENT format. 2) is the problem 1 worth of slight improvement over already good, but certainly not perfect rc.d subsystem. If someone would like to make new ports subsystem from scratch then it would be great. Would you like to ? ;) Certainly it will be great, as ports are certainly a mess, but it's quite a hell amount of work! lets assume someone working of port subsystem would prepare 3 well done ports per day average, then you need 20 people working for it for a year at least... when i would have million dollars handy call me and find these 20 people ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 04:17:52PM +0300, Vitaly Magerya wrote: The last time concurrent rc patches where proposed I measured boot time on my laptop (running 8.2-RELEASE i386 IIRC): out of 45 seconds from power on to login prompt, 20-25 where spent in rc, and parallel execution of it shaved off 7 seconds from boot time. OK, I stand corrected. mcl ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? We want you to do the work to prove that it is an improvement. Otherwise it's just another claim. rc subsystem is fine. Changing it would be another mess. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 8:19 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? We want you to do the work to prove that it is an improvement. Otherwise it's just another claim. rc subsystem is fine. Changing it would be another mess. Hi all, I wanted to jump in here. My name is Daniel Robbins and I'm the creator of Gentoo Linux and the original designer of the Gentoo initscripts, which now exist in rewritten form as OpenRC. FreeBSD inspired many of the concepts in Gentoo Linux. I see a great potential for collaboration here between Gentoo, Funtoo (my current project, a derivative/fork of Gentoo), FreeBSD and OpenRC (which is now an independently-managed project, distinct from the upstream distros) There has been some suggestion of a boot-time shoot-out, and it makes perfect sense to me that the OpenRC team would need to demonstrate the benefits of OpenRC first, before FreeBSD devs devote time to looking at OpenRC. But if boot time isn't a huge priority, then maybe it is the wrong place to focus. I think the big benefit of OpenRC to FreeBSD is that we are looking to continually improve it and include you in the requirements-gathering process for future development efforts. This means that we are able and willing to incorporate functionality that has been on your wish-list for some time, alleviating the burden of you having to do this work. Gentoo and Funtoo would also be able to benefit from any improvements that are made to OpenRC, so it is likely that you would see support from other OpenRC-using distros. So in this spirit, I would be interested in shifting the conversation to an effort to gather a list of semi-formal functional and non-functional requirements for a future FreeBSD initscript system. This would give the OpenRC team insight into what features would make OpenRC desireable to you and a serious candidate for inclusion in FreeBSD at some point in the future. Solaris SMF has already been mentioned. I would like to get a better understanding of your needs in this area. In 1999, Gentoo 0.99 was originally using supervise to ensure service availability (but was removed due to licensing quirks,) and we never quite got around to adding this functionality back in, so I would be interested in having similar functionality integrated into OpenRC as well. If there are any other things you would like to see in a future FreeBSD initscript system, please let us know. Note that I contribute to OpenRC but do not run the project. But I have a personal attachment to the system since it was originally my baby :) And of course I am willing to help where I can. Best Regards, Daniel Robbins ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
So let me know if you have any ideas for anything that would be considered more than just a slight improvement, that would make you go OK, now it's seriously worth considering OpenRC as this is more than just a nominal improvement in functionality. actually i am happy with current system, but maybe others. My most important ideas are: - any new system should not be more complex - ability to keep all flags and main config in single file (/etc/rc.conf) must persist. I don't want mess. And for sure not only me. - once again - the less files, the better. Some time ago i had to use linux (fortunately no longer needed). As i don't use it normally i just took debian installer that i remembered it WAS usable. After seeing the incredible complexity of /etc structure, not just rc scripts, i deleted most of it and put startup sequence in single file. It was plain horror. If someone would like to make new ports subsystem from scratch then it would be great. Would you like to ? ;) I know you are joking, but in all seriousness, this is another area of yes i am. but that joke is clear suggestion that we have already tens of thousands better or worse made ports! it's a good idea to stay in touch :) if you have idea how to improve existing rc.d AND make ports working as is then go on. Anyway i don't see rc.d subsystem to be such a big deal that great improvement are possible at all. For me it is OK. For a cases when i need really quick start or so - i just deleted it and put everything in /etc/rc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 9:28 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Whatever benefits are, and for sure they are think of this: 1) can it be compatible with 2 ports already made for FreeBSD, where many of them install rc.d scripts in CURRENT format. OK. This will clearly be needed, and shouldn't take too much time to investigate. 2) is the problem 1 worth of slight improvement over already good, but certainly not perfect rc.d subsystem. Yes, clearly OpenRC will need to offer significant improvements to make it worthwhile to justify migrating over to it. So let me know if you have any ideas for anything that would be considered more than just a slight improvement, that would make you go OK, now it's seriously worth considering OpenRC as this is more than just a nominal improvement in functionality. If someone would like to make new ports subsystem from scratch then it would be great. Would you like to ? ;) I know you are joking, but in all seriousness, this is another area of potential collaboration, because at some point I will be looking to significantly improve Portage. And Gentoo and Funtoo have the same challenging of upgrading ports systems -- there's so much stuff that already uses our *existing* ports system that needs to be moved over. There are creative solutions to this problem that I have found. So it's a good idea to stay in touch :) when i would have million dollars handy call me and find these 20 people ;) I have some ideas that should make it possible to transition ports systems with less effort than this. But this isn't related to the current thread :) Best Regards, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 05:51:10PM +0200, Wojciech Puchar wrote: So let me know if you have any ideas for anything that would be considered more than just a slight improvement, that would make you go OK, now it's seriously worth considering OpenRC as this is more than just a nominal improvement in functionality. actually i am happy with current system, but maybe others. My most important ideas are: - any new system should not be more complex Just to point out what may seem to only be a symantic issue, but can be significant. There is a difference between being complex and being complicated. Complex refers to the ability to handle a good variety of needs in a diverse environment. Complexity can mean adding the ability to work with current and know requirements as well as new - even yet to be discover - needs and circumstances. Complicated can mean making things require more steps or locations and/or exceptions and levels of abstraction to do the tasks than would be imposed in a well designed system. A well designed process handles a very complex set of needs without adding unnecessary complications. So, if Mr Puchar, in his comment, changes complex for complicated, then I think we can all agree with the wish that it does not add complication. But, a sophisticated complexity might be needed to handle all of the complications and diversity in the process. jerry - ability to keep all flags and main config in single file (/etc/rc.conf) must persist. I don't want mess. And for sure not only me. - once again - the less files, the better. Some time ago i had to use linux (fortunately no longer needed). As i don't use it normally i just took debian installer that i remembered it WAS usable. After seeing the incredible complexity of /etc structure, not just rc scripts, i deleted most of it and put startup sequence in single file. It was plain horror. If someone would like to make new ports subsystem from scratch then it would be great. Would you like to ? ;) I know you are joking, but in all seriousness, this is another area of yes i am. but that joke is clear suggestion that we have already tens of thousands better or worse made ports! it's a good idea to stay in touch :) if you have idea how to improve existing rc.d AND make ports working as is then go on. Anyway i don't see rc.d subsystem to be such a big deal that great improvement are possible at all. For me it is OK. For a cases when i need really quick start or so - i just deleted it and put everything in /etc/rc ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 3:23 PM, Mark Felder f...@feld.me wrote: On Wed, 20 Jun 2012 04:27:09 -0500, Fernando Apesteguía fernando.apesteg...@gmail.com wrote: Also, in embedded systems, boot time is an important factor. If you're designing a very specific embedded product based on FreeBSD why aren't you writing your own startup system? Why would anyone expect a general purpose out of the box OS to excel in a highly optimized embedded environment? I didn't say I was designing anything, I just said it is a factor. I've worked in some embedded projects in which the board had to be rebooted from time to time. In that case we needed/wanted the system to be up and running ASAP. Anyway, being a general purpose OS we can not expect FreeBSD to be installed on systems that almost never boot. That is not a reality IMHO. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/20/2012 11:28 AM, Wojciech Puchar wrote:
Hi all, I wanted to jump in here. My name is Daniel Robbins and I'm
the creator of Gentoo Linux and the original designer of the Gentoo
initscripts, which now exist in rewritten form as OpenRC. FreeBSD
inspired many of the concepts in Gentoo Linux.
I see a great potential for collaboration here between Gentoo, Funtoo
(my current project, a derivative/fork of Gentoo), FreeBSD and OpenRC
(which is now an independently-managed project, distinct from the
upstream distros)
stripped list of CC recipient - got too large.
Lets include the OpenRC developers in the conversation. Hopefully one of
them will add their two cents.
Note that I am not actually a part of the OpenRC development team. I do
stuff in Gentoo with ZFS (Linux), Clang and Gentoo FreeBSD.
There has been some suggestion of a boot-time shoot-out, and it makes
perfect sense to me that the OpenRC team would need to demonstrate the
benefits of OpenRC first, before FreeBSD devs devote time to looking
at OpenRC.
Whatever benefits are, and for sure they are think of this:
1) can it be compatible with 2 ports already made for FreeBSD, where
many of them install rc.d scripts in CURRENT format.
I believe that any combination of 3 possibilities can be done:
1. We could try to modify OpenRC could be modified to work with FreeBSD
init scripts.
2. We could convert the FreeBSD init scripts to the OpenRC format. On
Gentoo FreeBSD, we use the same init scripts we use on Gentoo Linux, so
this has not gotten much attention, but there have been a few
exceptions. In particular, I have converted encswap with only minor changes.
3. We could adapt Gentoo's init scripts. In theory, they should not
require modifications. In practice, exceptions are possible.
2) is the problem 1 worth of slight improvement over already good, but
certainly not perfect rc.d subsystem.
Code sharing among open source projects provides a deduplication of
work, which benefits everyone. Clang and ZFS are excellent examples of
this. Adoption of OpenRC in FreeBSD init system would enable us to pool
our resources, which should have similar benefits.
I will try to make time to write patches that import OpenRC into the
base system and then do some benchmarks. To be honest, I think that the
biggest advantage of OpenRC is the ease with which changes to the init
system's configuration are made.
Currently, you have 3 files that control things and what actually is
started is a juxaposition of them. With OpenRC, you can get a very
simple summary of what is started by doing `rc-update`. You can also
make changes such as adding sshd by doing `rc-update add sshd default`
or removing sshd by doing `rc-update remove sshd default`. It takes much
less time than typing out an editor command, finding the appropriate
entry (or making a new one), and making the change.
There is an open bug at Gentoo for a few init scripts that we are
missing. One is encswap and the conversion from FreeBSD's format to
OpenRC's format was quite simple:
https://bugs.gentoo.org/show_bug.cgi?id=420165
OpenRC init scripts lack much of the boiler plate code that FreeBSD's
init scripts contain. FreeBSD's syslogd init script is 72 lines in
length. OpenRC's syslogd init script is 19 lines in length and I
reproduce it below:
#!/sbin/runscript
# Copyright (c) 2007-2009 Roy Marples r...@marples.name
# Released under the 2-clause BSD license.
command=/usr/sbin/syslogd
command_args=$syslogd_args
case $RC_UNAME in
FreeBSD|DragonFly) pidfile=/var/run/syslog.pid;;
*) pidfile=/var/run/syslogd.pid;;
esac
name=System Logger Daemon
depend()
{
provide logger
use net newsyslog
need localmount
after bootmisc
}
There is clearly much more boilerplate code in the FreeBSD counterpart.
The syslogd script is unusually short for an OpenRC init script, so I
present pf for something a bit more representative:
#!/sbin/runscript
# Copyright (c) 2007-2009 Roy Marples r...@marples.name
# Released under the 2-clause BSD license.
name=Packet Filter
: ${pf_conf:=${pf_rules:-/etc/pf.conf}}
required_files=$pf_conf
extra_commands=checkconfig showstatus
extra_started_commands=reload
depend() {
need localmount
keyword -jail
}
start()
{
ebegin Starting $name
if type kldload /dev/null 21; then
kldload pf 2/dev/null
fi
pfctl -q -F all
pfctl -q -f $pf_conf $pf_args
pfctl -q -e
eend $?
}
stop()
{
ebegin Stopping $name
pfctl -q -d
eend $?
}
checkconfig()
{
ebegin Checking $name configuration
pfctl -n -f $pf_conf
eend $?
}
reload()
{
ebegin Reloading $name rules.
pfctl -q -n -f $pf_conf \
{
# Flush everything but existing state entries that way when
# rules are read in, it doesn't break established
connections.
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Jun 20, 2012, at 11:43 AM, Daniel Robbins drobb...@funtoo.org wrote: On Wed, Jun 20, 2012 at 9:28 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Whatever benefits are, and for sure they are think of this: 1) can it be compatible with 2 ports already made for FreeBSD, where many of them install rc.d scripts in CURRENT format. OK. This will clearly be needed, and shouldn't take too much time to investigate. 2) is the problem 1 worth of slight improvement over already good, but certainly not perfect rc.d subsystem. Yes, clearly OpenRC will need to offer significant improvements to make it worthwhile to justify migrating over to it. So let me know if you have any ideas for anything that would be considered more than just a slight improvement, that would make you go OK, now it's seriously worth considering OpenRC as this is more than just a nominal improvement in functionality. If someone would like to make new ports subsystem from scratch then it would be great. Would you like to ? ;) I know you are joking, but in all seriousness, this is another area of potential collaboration, because at some point I will be looking to significantly improve Portage. And Gentoo and Funtoo have the same challenging of upgrading ports systems -- there's so much stuff that already uses our *existing* ports system that needs to be moved over. There are creative solutions to this problem that I have found. So it's a good idea to stay in touch :) when i would have million dollars handy call me and find these 20 people ;) I have some ideas that should make it possible to transition ports systems with less effort than this. But this isn't related to the current thread :) For one thing, it depends on how different the new ports system is. We migrated MidnightBSD's mports in about a year for roughly 2000 ports with four people, but that was a refactor of FreeBSD ports rather than a whole new system. The biggest problems were related to installing into a fake root as many plists were terribly bad. There are classes of problems like perl ports or gnu autotools which tend to have common solutions. In our case, we wanted some compatibility due to the limited resources we had. Looking at modern FreeBSD, most of the problems have been solved by automated testing and hard work by the ports people. I personally think the problem now is packages. They must be updated and the tools must be better to upgrade. I know several folks are working on it and both midnightbsd and pc-bsd have solutions to look at there as well. As far as rc goes, I think it is slow for some setups and reasonable for others. Kernel boot time needs improvement as well as loading kernel modules. There isn't a one size fits all fix for the boot time problem. Maybe a bunch of little improvements would help the most folks. rcorder caching or something ? Luke___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 9:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: actually i am happy with current system, but maybe others. My most important ideas are: - any new system should not be more complex - ability to keep all flags and main config in single file (/etc/rc.conf) must persist. I don't want mess. And for sure not only me. - once again - the less files, the better. Some time ago i had to use linux (fortunately no longer needed). As i don't use it normally i just took debian installer that i remembered it WAS usable. After seeing the incredible complexity of /etc structure, not just rc scripts, i deleted most of it and put startup sequence in single file. It was plain horror. I think our current system for OpenRC is pretty elegant. Initscripts go in /etc/init.d. Runlevels are defined as directories in /etc/runlevels. The default runlevel is /etc/runlevels/default. To add a service to a runlevel, you type rc-update add service runlevelname. To start/stop all services according to runlevel, you type rc. To switch runlevels, you type rc runlevel, like rc mobile. yes i am. but that joke is clear suggestion that we have already tens of thousands better or worse made ports! Well, if ports maintenance is the much bigger problem we can also look at coordinating efforts there in the future. if you have idea how to improve existing rc.d AND make ports working as is then go on. I think that if FreeBSD used OpenRC (maybe initially with a compatibility layer for existing initscripts) then it would make it easier for us all to transition to a compatible ports format, since we could use the same ports initscripts. Then, an nginx port could contain an initscript that could work on both FreeBSD and Gentoo/Funtoo Linux. This could definitely open up the possibility of collaborating more easily in the future on ports maintenance. But collaborating on ports is such a big topic, and initscript compatibility is a relatively minor issue in the grand scheme of things. Is the maintenance of ports a huge issue for FreeBSD, and would you be interested in looking into working with Gentoo and Funtoo on sharing build scripts? For me it is OK. You know, I often wonder why so much effort in the Linux world is spent on the first few seconds of a system's uptime. So I definitely understand and appreciate that you are not ready to make reckless changes to your boot process. From my perspective, the upstart/launchd/systemd/udev mess in Linux is ugly, and we are promoting OpenRC as a sane alternative. So it helps us to have other distributions and operating systems using it. Because for Gentoo and Funtoo, OpenRC *is* our standard design, and we want to promote something more normal than the other stuff coming from Linux. It helps us to fight that battle when we have a broader base of users. I think that is one of the motivations of reaching out to FreeBSD -- the Gentoo and Funtoo user-base is more aligned with the sensibilities of FreeBSD than the other Linux distros moving to upstart/launchd, etc. I think that may be a major benefit of FreeBSD using OpenRC -- that you will be treated as a respected and listened-to member of the OpenRC community. I don't know if you have been following some of the politics in Linux recently, but a lot of this service management stuff has been almost shoved down our throats with the justification that it's necessary for Linux dominating the desktop. (!) Best Regards, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 20.06.2012, 18:13 Uhr, schrieb Daniel Robbins drobb...@funtoo.org: To add a service to a runlevel, you type rc-update add service runlevelname. To start/stop all services according to runlevel, you type rc. To switch runlevels, you type rc runlevel, like rc mobile. Just to clarify: In OpenRC I can have *arbitrary* runlevels? Not like as I remember from years ago when I used Linux, runlevel 1 2 3 4 5, but any number of default online maintenance, and thus I'd have *sets* of services I could conveniently start and stop together? But there is no possibility of separating base system /etc and ports /usr/local/etc? The separation between the two is something I'd not want to loose. Michael ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
So, if Mr Puchar, in his comment, changes complex for complicated, then I think we can all agree with the wish that it does not add complication. right. i mean complicated or overcomplex. If anyone still don't know what i mean, i recommend installing any of those trendy new cool flashy linux distro like ubuntu ;) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
I think our current system for OpenRC is pretty elegant. Initscripts go in /etc/init.d. Runlevels are defined as directories in /etc/runlevels. The default runlevel is /etc/runlevels/default. in FreeBSD you must handle /etc/* and /usr/local/etc/* - one for base system rest for ports. runlevels are quite linuxism IMHO. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
# rc maintenance # rc online this functionality seems useful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 1:52 PM, Michael Ross g...@ross.cx wrote: Just to clarify: In OpenRC I can have *arbitrary* runlevels? Not like as I remember from years ago when I used Linux, runlevel 1 2 3 4 5, but any number of default online maintenance, and thus I'd have *sets* of services I could conveniently start and stop together? Yes, this is what OpenRC offers. You can even have one runlevel be a child of another runlevel. All runlevels have logical names. By default, the system boots into default. These are mapped to old-school 1 2 3 4 5 runlevels under linux since we are still using sysvinit, 3 maps to default. But you can change after boot: # rc maintenance # rc online etc. This doesn't change the hard runlevel (3) but it changes the OpenRC logical runlevel. Basically, this convenient system is compatible with traditional linux numerical runlevels but does depend on them. But there is no possibility of separating base system /etc and ports /usr/local/etc? The separation between the two is something I'd not want to loose. I don't think it would be a very huge leap at all to map in both system and ports scripts. It would likely be a relatively straightforward patch if it is not already supported. Regards, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 8:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: Some time ago i had to use linux (fortunately no longer needed). As i don't use it normally i just took debian installer that i remembered it WAS usable. After seeing the incredible complexity of /etc structure, not just rc scripts, i deleted most of it and put startup sequence in single file. It was plain horror. You would weep if you saw Solaris's SMF, then. Everything is controlled by XML files, which you have to install and uninstall via the black-box 'svcadm' and 'svcs' commands. It's the most opaque init system I've ever seen. Lots of neat features, but I never feel confident I'm dealing with it right, especially when trying to implement a new service. rc.d-style init scripts aren't *that* bad, but some of the new parallel init systems are quite confusing. I recently spent most of a day trying to figure out why Ubuntu wouldn't launch a new rc script I'd installed before realizing that the parallel init system it uses simply silently ignores scripts that don't indicate their dependencies in a way it understands. -- David Brodbeck System Administrator, Linguistics University of Washington ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins drobb...@funtoo.org wrote: This doesn't change the hard runlevel (3) but it changes the OpenRC logical runlevel. Basically, this convenient system is compatible with traditional linux numerical runlevels but does depend on them. Meant to type: does NOT depend on them. Here is a bit more info: Runlevel-specific conf.d files: http://www.funtoo.org/wiki/Funtoo_Linux_Networking#Alternate_Configs Stacked runlevels (this is a more sophisticated feature than just creating a duplicate, separately-managed runlevel): http://www.funtoo.org/wiki/Stacked_Runlevels To create a separately-managed runlevel, you would just: # mkdir /etc/runlevels/maintenance # rc-update add maintenance svc1 # rc-update add maintenance svc2 # rc-update add maintenance svc1 You could then switch by typing: # rc maintenance Anything not in the maintenance runlevel that is currently running would be stopped, and any new services in maintenance that are not running would be started. Regards, Daniel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 20.06.2012, 22:29 Uhr, schrieb Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: # rc maintenance # rc online this functionality seems useful. That's... not the word I'd have used. I'm sort-of-emulating this using custom scripts quite often, and especially with the stacked runlevel variety, this is something I really would like to have. http://www.funtoo.org/wiki/Stacked_Runlevels shows the possibility of multiple network configs, too, if I read this right, i could have # rc online with 2 children: # rc online-devel vs # rc online-demo to have the same services, but different network settings, without (un)commenting lines in rc.conf before and after the on-site demonstration. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, Jun 20, 2012 at 1:28 PM, Daniel Robbins drobb...@funtoo.org wrote: On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins drobb...@funtoo.org wrote: This doesn't change the hard runlevel (3) but it changes the OpenRC logical runlevel. Basically, this convenient system is compatible with traditional linux numerical runlevels but does depend on them. Meant to type: does NOT depend on them. Here is a bit more info: Runlevel-specific conf.d files: http://www.funtoo.org/wiki/Funtoo_Linux_Networking#Alternate_Configs Stacked runlevels (this is a more sophisticated feature than just creating a duplicate, separately-managed runlevel): http://www.funtoo.org/wiki/Stacked_Runlevels To create a separately-managed runlevel, you would just: # mkdir /etc/runlevels/maintenance # rc-update add maintenance svc1 # rc-update add maintenance svc2 # rc-update add maintenance svc1 You could then switch by typing: # rc maintenance Anything not in the maintenance runlevel that is currently running would be stopped, and any new services in maintenance that are not running would be started. There's no need to do a wholesale replacement of the RC system in FreeBSD to support this concept. What you are describing are service profiles. And we already have a single file that describes the default service profile for FreeBSD: /etc/rc.conf. That lists every service that should be started (or stopped). All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other - monitor running services and restart them if they crash Compared to all the init/RC systems on Linux, ours has *many* advantages, not the least of which are: - very simple text configuration file - only 2 directories of init scripts to worry about (/etc/rc.d; /usr/local/etc/rc.d) - ability to create generic or global config file (/etc/rc.conf) with local overrides (/etc/rc.conf.local) - ability to see the exact order that things will start (or stop) via rcorder - everything is written in nice, simple, sh We don't need to replace a perfectly working system. Maybe it needs improving, but it doesn't need replacing. -- Freddie Cash fjwc...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 2012-Jun-20 09:05:05 -0600, Daniel Robbins drobb...@funtoo.org wrote: I see a great potential for collaboration here between Gentoo, Funtoo (my current project, a derivative/fork of Gentoo), FreeBSD and OpenRC (which is now an independently-managed project, distinct from the upstream distros) The more different projects can share common code, the better. But if boot time isn't a huge priority, then maybe it is the wrong place to focus. Boot time is an issue for some people - even people with never rebooted servers need fast boot times when they _do_ need to reboot (hardware failures, kernel security fixes) to get that last '9' of uptime. I think the big benefit of OpenRC to FreeBSD is that we are looking to continually improve it and include you in the requirements-gathering process for future development efforts. Even if FreeBSD doesn't switch to OpenRC, it's definitely worth looking at the shortcomings of the current rc system and how it could be improved. The most obvious ones (IMHO) are: - Lack of dependency handling for manual start/stop - No provision to automatically restart a daemon if it dies. Solaris SMF has already been mentioned. As someone who has had the misfortune to use it, I would say that the underlying concept is nice but the implementation is a disaster. In particular, _everything_ is different to traditional Unix init systems. The systems administrator needs to learn a completely new mindset for interacting with the init system and the package developer has to develop completely different service management scripts. On 2012-Jun-20 17:28:45 +0200, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: 1) can it be compatible with 2 ports already made for FreeBSD, where many of them install rc.d scripts in CURRENT format. The dependency information should already be encoded in both base and ports rc scripts. Unfortunately, it looks like OpenRC encodes the information in a different way, so it's not just a plugin replacement. One task for anyone wanting to integrate OpenRC would be working out how to handle this - preferably without rewriting every rc script. Since we already have dependency information, there is no technical reason why a tool like rcorder(8) couldn't indicate that particular scripts or groups of scripts could run in parallel. In practice, I expect that doing so will turn up a large number of scripts which have incorrect dependency information which has been masked by the current serial processing. Anyone implementing parallel rc processing will need to be able to distinguish between errors in their tools and errors in the actual rc scripts. I know dougb@ regularly picks up issues with new updated ports but it's not realistic to rely on him manually picking up every rc script error. -- Peter Jeremy pgpvt6oBaRAkM.pgp Description: PGP signature
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
scripts, i deleted most of it and put startup sequence in single file. It was plain horror. You would weep if you saw Solaris's SMF, then. Everything is i don't really know what i've seen. i've installed latest solaris demo downloaded from oracle. After nearly an hour of installation over which i had really no control and no real clue what's going on i finally after over 5 minutes got the system booted, logged as root and tried to understand the /etc tree, boot process and gave up really quickly. just seeing a files and directories (both numerous) of just a kernel binaries was truly enough. Now... lets go back to FreeBSD which is controllable and understandable by a human. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
To create a separately-managed runlevel, you would just: # mkdir /etc/runlevels/maintenance # rc-update add maintenance svc1 # rc-update add maintenance svc2 # rc-update add maintenance svc1 seems already not nice. Cannot i just edit one file to do this using my favourite text editor? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
The more different projects can share common code, the better. as long as we share good code and good ideas. Boot time is an issue for some people - even people with never rebooted servers need fast boot times when they _do_ need to reboot speeding up anything is always good. I think the big benefit of OpenRC to FreeBSD is that we are looking to continually improve it and include you in the requirements-gathering process for future development efforts. Even if FreeBSD doesn't switch to OpenRC, it's definitely worth looking at the shortcomings of the current rc system and how it could be improved. The most obvious ones (IMHO) are: - Lack of dependency handling for manual start/stop which is not really a problem and often an adventage. - No provision to automatically restart a daemon if it dies. but it should not be a part of rc subsystem at all. First - deamons should not die without reason. If they do, admin should clearly know it and feel it's effects, and after fixing a source problem , restart it manually. in case when you are for some reason required (temporarily of course) to use daemons that often dies, then just make restart wrapper shell script and put it in place of actual daemon in rc.d script. This is what i do with asterisk process that rarely but do crash. But i did it myself and any responsible admin should do this himself, knowing a problem. The proposition sounds for me somehow like windows XP/7 solution that restarts services and windows explorer so it doesn't fail. Such ideas and methods of constructing operating environment is possibly acceptable under linux community, MAYBE for PC-BSD, but not for anything serious. there is IMHO already too much automata in default FreeBSD: default /etc/crontab, /etc/newsyslog.conf and /etc/periodic directory. All gets deleted by me as soon as i install FreeBSD. All of this mechanisms are good, but none should be in default system install with possible exception: */5 * * * * root/usr/libexec/atrun */11* * * * operator /usr/libexec/save-entropy Everything else should be run after clear request and knowledge of sysadmin. scripts from /etc/periodic should go to /usr/share/examples ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
# rc maintenance # rc online this functionality seems useful. That's... not the word I'd have used. I'm sort-of-emulating this using custom scripts quite often, true. custom script that do lots of start or stops are good. But with N2 runlevels without this subsystem you would need to run multiple of them or have N*(N-1) scripts. But i don't like the idea of executing commands to add new runlevels, configure it etc. I like the idea of single config file, or POSSIBLY integrating it in rc.conf service_enable=YES could be replaced by service1_enable=YES service1_disable=maintenance blah service2_enable=maintenance which means service1 should be stopped at runlevels maintenance and blah, and service2 enabled only at runlevel maintenance. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 20.06.2012, 23:42 Uhr, schrieb Freddie Cash fjwc...@gmail.com: On Wed, Jun 20, 2012 at 1:28 PM, Daniel Robbins drobb...@funtoo.org wrote: On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins drobb...@funtoo.org wrote: This doesn't change the hard runlevel (3) but it changes the OpenRC logical runlevel. Basically, this convenient system is compatible with traditional linux numerical runlevels but does depend on them. Meant to type: does NOT depend on them. Here is a bit more info: Runlevel-specific conf.d files: http://www.funtoo.org/wiki/Funtoo_Linux_Networking#Alternate_Configs Stacked runlevels (this is a more sophisticated feature than just creating a duplicate, separately-managed runlevel): http://www.funtoo.org/wiki/Stacked_Runlevels To create a separately-managed runlevel, you would just: # mkdir /etc/runlevels/maintenance # rc-update add maintenance svc1 # rc-update add maintenance svc2 # rc-update add maintenance svc1 You could then switch by typing: # rc maintenance Anything not in the maintenance runlevel that is currently running would be stopped, and any new services in maintenance that are not running would be started. There's no need to do a wholesale replacement of the RC system in FreeBSD to support this concept. What you are describing are service profiles. And we already have a single file that describes the default service profile for FreeBSD: /etc/rc.conf. That lists every service that should be started (or stopped). All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. ... and to be able to switch between two configurations at runtime, without taking down services listed active in both configurations preferably. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other - monitor running services and restart them if they crash Compared to all the init/RC systems on Linux, ours has *many* advantages, not the least of which are: - very simple text configuration file - only 2 directories of init scripts to worry about (/etc/rc.d; /usr/local/etc/rc.d) - ability to create generic or global config file (/etc/rc.conf) with local overrides (/etc/rc.conf.local) - ability to see the exact order that things will start (or stop) via rcorder - everything is written in nice, simple, sh We don't need to replace a perfectly working system. Maybe it needs improving, but it doesn't need replacing. Yes. I don't even think it *needs* improving, but service profiles including network profiles would be really nice and worth looking into. If we can get that without loosing the simple text-file-based configuration, the better. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/19/2012 12:39 AM, Wojciech Puchar wrote: - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:39 AM, Wojciech Puchar wrote: - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. Assuming that the hacks aren't working around other issues, like routes not already being available for a certain period of time, e.g. defaultroute, etc (which doesn't work 100% of the time, e.g. static gateways and mounting NFS shares). This is something that launchd, systemd, upstart, etc handle (because they either have more knowledge of the system or it's been coded into the files that execute the jobs/services), or alternatively the services need to fail more gracefully (this is more difficult -- but not impossible -- to code). Even OpenRC in gentoo doesn't handle this, unless things have changed dramatically since I used Gentoo ~2 years ago... Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, 19 Jun 2012 01:04:47 -0400 Richard Yao wrote: On 06/19/2012 12:39 AM, Wojciech Puchar wrote: - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. That's not the reason for the sleeps. FreeBSD sorts the scripts into dependency order and runs them sequentially, so there's no reason to sleep waiting for a dependency script to complete. The sleeps exist for a variety of reasons. Just looking at the grep can be a bit misleading. Not all of the scripts are going to be used, the sleep is not always relevant to startup, in some case it's in a code path that's not typically taken. One thing that I think could be easily improved is that the polling delays could be changed from 1 second to 0.1 seconds. If there's a reason for rc scipts needing to be portable, there could be a polling delay function with a fast polling option in defaults/rc.conf. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/19/2012 07:20 AM, Garrett Cooper wrote: On Mon, Jun 18, 2012 at 10:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:39 AM, Wojciech Puchar wrote: - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. OpenRC init scripts lack such delays. They store dependency information, which enables OpenRC to start them as soon as their dependencies are ready. Assuming that the hacks aren't working around other issues, like routes not already being available for a certain period of time, e.g. defaultroute, etc (which doesn't work 100% of the time, e.g. static gateways and mounting NFS shares). This is something that launchd, systemd, upstart, etc handle (because they either have more knowledge of the system or it's been coded into the files that execute the jobs/services), or alternatively the services need to fail more gracefully (this is more difficult -- but not impossible -- to code). Even OpenRC in gentoo doesn't handle this, unless things have changed dramatically since I used Gentoo ~2 years ago... Thanks! -Garrett It works for me. I suggest you try Gentoo FreeBSD in a jail: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 6/18/2012 9:39 PM, Wojciech Puchar wrote: The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. In the ports' scripts we tend to be more forgiving, but I've worked with several maintainers to apply more effective solutions where there is a good reason to wait for a dependent service to actually be running. This also brings up a good point, any new rc-alike solution we consider must have support for scripts in ports that is at least as robust as what we have now. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
sorry i was wrong /etc/rc.d/defaultroute use sleep to wait for dhclient only. On Tue, 19 Jun 2012, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Doug Would you elaborate on what you consider to be a robust test? I really have no idea. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Thanks, -Garrett Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. Change /etc/rc to use OpenRC in the base system. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/19/2012 06:17 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. Change /etc/rc to use OpenRC in the base system. -Garrett That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. People can use Gentoo FreeBSD in jails (or on physical hardware) to do comparisons. If they like it, Gentoo's developers are willing to help, but you cannot expect us to do your work for you. That would be like asking the Clang developers to replace your system compiler or the Illumos developers to replace your file system. FreeBSD's developers need to be the ones to import OpenRC into FreeBSD's base system, not us. We will just fix problems you encounter and collaborate on improvements. That is what every other upstream does. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 3:45 PM, Richard Yao r...@funtoo.org wrote: On 06/19/2012 06:17 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 3:04 PM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 04:12 PM, Garrett Cooper wrote: On Tue, Jun 19, 2012 at 11:12 AM, Richard Yao r...@gentoo.org wrote: On 06/19/2012 12:50 PM, Doug Barton wrote: On 6/18/2012 4:05 PM, Richard Yao wrote: Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Bt! Thanks for playing. :) You're the one proposing the change, YOU get to do the performance comparisons. If you want a rough idea of what I personally would consider to be a robust test, don't hesitate to ask. I'm sure others would have ideas as well. Would you elaborate on what you consider to be a robust test? I really have no idea. It might be an ok smoke test, but it's hardly a realistic test/comparison as the pseudo startup for a jail and a real system aren't close to being the same (this is in part because of how jails function). Would you elaborate on what you consider to be acceptable? Honestly, I am not certain if you will appreciate any tests unless you do them yourself. Change /etc/rc to use OpenRC in the base system. -Garrett That is already done in Gentoo FreeBSD, or do you want me to do the work for you to integrate OpenRC in the base system? I already have OpenRC in Gentoo FreeBSD. Taking the time to integrate OpenRC into FreeBSD would be an inefficient use of my time. Not only would I fail to gain any improvements on my systems, but I would divert development time from things that do benefit me. People can use Gentoo FreeBSD in jails (or on physical hardware) to do comparisons. If they like it, Gentoo's developers are willing to help, but you cannot expect us to do your work for you. That would be like asking the Clang developers to replace your system compiler or the Illumos developers to replace your file system. FreeBSD's developers need to be the ones to import OpenRC into FreeBSD's base system, not us. We will just fix problems you encounter and collaborate on improvements. That is what every other upstream does. No. I'm saying that this is what would need to be done to qualify it and it would need to be run with the base system and a series of rc scripts in ports. In order for things to ultimately be committed, things would need to be regression tested enough that FreeBSD developers would be confident with the end-result. And yes, there would need to be a conversion plan, documentation update, and the full nine yards for whatever's done with an rc replacement, as this would impact a lot of folks and projects. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, 19 Jun 2012 11:03:31 -0700 Garrett Cooper wrote: On Tue, Jun 19, 2012 at 10:51 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: grep sleep /etc/rc.d/* usr/local/etc/rc.d/* Sleeps in /etc tend to be there for good reasons, and new ones are vigorously scrutinized. If you see any that you think are dubious, feel free to mention them on freebsd-rc@. I don't say they are not needed but that they exist. anyway i don't understand sleep 1 after setting default route. Probably working around annoying races in the driver / network / routing stack. Please see my previous reply. There are a few sleeps where some action is performed and and then a fixed sleep is done, but this is one of the ones where the sleep is in a while loop - a full second seems a bit long. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote: On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, [...] Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. Launchd is strikingly similar to SMF, which probably isn't a coincidence, knowing how much other code Apple pulled from Solaris during those days. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
Replacing rc(8) has a lot of risks and not many benefits. Current system if you make single-use system (for eg. X11 terminal) just delete most of files from /etc including /etc/rc and write your own - the simplest possibe, just put command to run all needed things. that's all. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 18/06/2012 09:11, Atte Peltomäki wrote: On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote: On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, [...] Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. Launchd is strikingly similar to SMF, which probably isn't a coincidence, knowing how much other code Apple pulled from Solaris during those days. There was even some work done to get it working for FreeBSD if anyone feels like taking it up again. http://wiki.freebsd.org/launchd ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/18/2012 01:12 PM, Vincent Hoffman wrote: On 18/06/2012 09:11, Atte Peltomäki wrote: On Fri, Jun 15, 2012 at 03:43:37PM -0400, Outback Dingo wrote: On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, [...] Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. Launchd is strikingly similar to SMF, which probably isn't a coincidence, knowing how much other code Apple pulled from Solaris during those days. There was even some work done to get it working for FreeBSD if anyone feels like taking it up again. http://wiki.freebsd.org/launchd Would someone elaborate on what launchd and SMF do well in comparison to OpenRC (or FreeBSD's init)? Gentoo does active OpenRC development. If there is anything that it could do better, please do not hesitate to let us know so that improvements can be made. Would licensing be a problem for either SMF or launchd? I know that CDDL code is not allowed in GENERIC kernels, so I would be surprised if SMF would be acceptable for FreeBSD's init system. I am not sure what the situation is for Apache 2.0 licensed code, but I would think that FreeBSD would code that is available under the 2-clause BSD license. With that said, the Gentoo developers already have OpenRC working on FreeBSD and OpenRC is available under the 2-clause BSD license, so it should have a compatible license. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
As the original poster of this thread, I can also say that Doug is correct. The issue is not rc, it is the actual kernel boot process. Maybe I could see rc becoming an issue in a massive server environment where there are a lot of userland processes to start, but that delay would most likely be in the programs themselves and not rc (I think of rc as more of a dispatcher). When it comes to a desktop/laptop/simple server and all you do with rc is configure a static IP, start dbus/hal/sshd, and maybe launch a few jails... at least 90-98% of the boot process is spent doing the kernel work. -Brandon On 6/18/2012 6:53 PM, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On 06/18/2012 06:53 PM, Doug Barton wrote: It's unfortunate that this thread evolved into a discussion about replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost certainly isn't going to help the goal of actually making the boot time faster. But, I'm willing to be proven wrong by someone who actually _implements_ one of these systems and can demonstrate, in a statistically rigorous fashion, how much the boot time is improved. Doug Doug, we already have OpenRC implemented. You can install Gentoo FreeBSD in a jail, install regular FreeBSD in another jail and do your own performance comparisons. Here are instructions: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail Is there anything else that you need? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. indeed. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. most of boot time consist of - delay in bootloader. setting autoboot_delay can partially delay it, delay to zero can be achieved by patching first stage booter that too add delay - delay in kernel initialization. making custom kernel helps of course but still it takes eg 10 seconds on my laptop. putting things that are not needed instantly at boot - as module - may help. USB being prime example. - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Tue, Jun 19, 2012 at 6:39 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: replacing rc.d, since that's almost certainly not relevant to the original topic of improving the overall boot time. indeed. If you analyze the boot process thoroughly you should see that out of the total time taken to boot, nearly 0 is spent by rc.d actually doing something. Almost all of the actual time is spent waiting for other stuff, either the kernel (primarily) or the services that the system is running actually starting up. most of boot time consist of - delay in bootloader. setting autoboot_delay can partially delay it, delay to zero can be achieved by patching first stage booter that too add delay - delay in kernel initialization. making custom kernel helps of course but still it takes eg 10 seconds on my laptop. putting things that are not needed instantly at boot - as module - may help. USB being prime example. - delay at rc.d scripts - there are some delays inserted. The latter item is the only place where making changes to rc.d is going to help, and only then by parellelizing, and even then you are not really going to gain much since most things at boot time are serial. grep sleep /etc/rc.d/* usr/local/etc/rc.d/* So while talk of how to get your favorite boot-time manager into FreeBSD may be entertaining, it's not likely to be productive, and almost it is unimportant as FreeBSD don't crash. Please, re-read already sent mails in this thread about that statement so we don't get stuck in a loop. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
On 2012-Jun-13 21:55:22 +0200, Hans Petter Selasky hsela...@c2i.net wrote: Try setting: sysctl hw.usb.no_boot_wait=1 Note that this is a tunable and will need to be specified in /boot/loader.conf to have any effect. -- Peter Jeremy pgpojiOBCDYfk.pgp Description: PGP signature
Replacing rc(8) (Was: FreeBSD Boot Times)
On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, even though it's UI is somewhat irritating. When configured correctly, you can trust SMF to deal with any problem; when a needed resource for a given service is down, that service isn't started. When the service is malfunctioning, it's restarted at a configured interval or marked as malfunctioning and stopped and admin is contacted. And so forth. Faster boot times come as a simple added bonus from proper design. Anyone serious about replacing rc(8) should take a good look at SMF feature list, then decide if such a thing is worth spending time reimplementing. Doing a dozen half-assed implementations like Linux is doing is just dumb and aggravates sysadmins. Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Fri, Jun 15, 2012 at 8:48 AM, Atte Peltomäki atte.peltom...@iki.fi wrote: On Thu, Jun 14, 2012 at 02:09:38PM -0400, Richard Yao wrote: Also, I am certain that the OpenRC developers would be thrilled if FreeBSD adopted OpenRC. If FreeBSD core is interested in OpenRC, feel free to contact the OpenRC and/or the Gentoo FreeBSD developers. We would all love to see OpenRC in upstream FreeBSD. Replacing rc(8) has a lot of risks and not many benefits. Current system is somewhat limited, but it works, it's simple to understand and everyone already knows it and uses it. Solaris SMF is by far the most advanced bootup/service manager I've come across, even though it's UI is somewhat irritating. When configured correctly, you can trust SMF to deal with any problem; when a needed resource for a given service is down, that service isn't started. When the service is malfunctioning, it's restarted at a configured interval or marked as malfunctioning and stopped and admin is contacted. And so forth. Faster boot times come as a simple added bonus from proper design. Anyone serious about replacing rc(8) should take a good look at SMF feature list, then decide if such a thing is worth spending time reimplementing. Doing a dozen half-assed implementations like Linux is doing is just dumb and aggravates sysadmins. Personally, as much as I like power of SMF, I think FreeBSD devs have much more important (and interesting) things to do. Theres always Launchd also. -- Atte Peltomäki atte.peltom...@iki.fi http://kameli.org Your effort to remain what you are is what limits you ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
Thanks for the information -- I got scared by SysV init. This actually does look very nice. -Nathan On 06/13/12 13:35, Richard Yao wrote: The OpenRC is sysvinit compatible, but it has few of sysvinit's flaws. It has named runlevels, the presence of an init script does not cause it to start and it is in my opinion a joy to use. I suggest that you try OpenRC before drawing conclusions. You can install Gentoo FreeBSD in a jail. There are instructions for this on the Gentoo wiki: http://wiki.gentoo.org/wiki/Gentoo_FreeBSD#Howto_run_G.2FFBSD_in_vanilla_FreeBSD.27s_jail If you find deficiencies, I am certain that the OpenRC developers would appreciate feedback regarding them. On 06/13/12 10:19, Nathan Whitehorn wrote: On 06/12/12 18:00, Richard Yao wrote: On 06/11/12 18:51, Garrett Cooper wrote: On Mon, Jun 11, 2012 at 3:21 PM, Brandon Falkbfalk_...@brandonfa.lk wrote: Greetings, I was just wondering what it is that FreeBSD does that makes it take so long to boot. Booting into Ubuntu minimal or my own custom Linux distro, literally takes 0.5-2 seconds to boot up to shell, where FreeBSD takes about 10-20 seconds. I'm not sure if anything could be parallelized in the boot process, but Linux somehow manages to do it. The Ubuntu install I do pretty much consists of a shell and developers tools, but it still has a generic kernel. There must be some sort of polling done in the FreeBSD boot process that could be parallelized or eliminated. Anyone have any suggestions? Note: This isn't really an issue, moreso a curiosity. The single process nature of rc is a big part of the problem, as is the single AP bootup of FreeBSD right before multiuser mode. There are a number of threads that discuss this (look for parallel rc bootup or something like that in the current, hacker, and rc archives -- the most recent discussion was probably 6~9 months ago). Given past experience, a big part of getting past the parallelized rc mess would be to make services fail/wait gracefully for all their resources to come up before proceeding. It's not easy, but it's possible with enough resources. HTH, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Gentoo FreeBSD shares OpenRC with Gentoo Linux. OpenRC is a BSD 2-clause licensed System V init system replacement that supports parallel boot. Its boot performance is competitive with systemd and Ubuntu's upstart. If FreeBSD's init system is serializing the boot process, it might be worthwhile to consider importing OpenRC. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Please don't change any of the user-facing aspects of the RC system. One of the things that brought me (and many others I know) to FreeBSD, besides working sound, was having an rc.conf that was easy to configure instead of the nightmare that is System V init. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
