MAGIC with HP KVM - someone will help?
i am not sure if it is related at all to FreeBSD, but maybe someone here know the solution. Anyway it is somewhat FreeBSD related for sure as you will see from description. I bought used IP 16 port KVM connected to few servers, in between them FreeBSD 8 server running on Dell PowerEdge T110. As this KVM have PS/2 connectors to keyboard and mouse i added USB to dual-PS/2 converter. So: 1)when KVM is used locally with plugged monitor, keyboard and mouse everything is fine. 2)when it is used remotely before FreeBSD is booted or after successful multiuser boot everything is fine. 3)when kernel boots and waits for GELI password, and i SLOOOWLY type it (at most one keypress per second) over remote KVM connection - everything is fine. 4)when i type the password faster keyboard locks. you have to turn off server and on again to recover. Please don't laught from 3 and 4 as it is true, tested several times. The problem happens ONLY at FreeBSD but before mounting root, when geli ask for password. And it is serious as ability to enter geli password is the main reason for this KVM to be installed! And really not forgetting to type password very slowly isn't easy. Any idea what it is and how to fix it. It really looks like magic. ___ 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
Are there any plans to increase the username length?
Hi Looks like FreeBSD one of the few modern OS which have the maximum length of username less than 255. Windows: http://technet.microsoft.com/en-us/library/cc783323.aspx (255) Linux: getconf LOGIN_NAME_MAX = 256 MacOSX: getconf LOGIN_NAME_MAX = 255 FreeBSD: getconf LOGIN_NAME_MAX = 17 Any plan to catch up with other OSes? ___ 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: /etc/resolv.conf getting over written with dhcp
Ian Lepore wrote: Using the 'prepend' or 'supercede' keywords in /etc/dhclient.conf is pretty much the standard way of handling a mix of static and dhcp interfaces where the static config needs to take precedence. I'm not sure why you dismiss it as essentially good, but somehow not good enough. It's been working for me for years. -- Ian The issue that I had indicated that the issue with the /etc/resolv.conf is being caused by an error in /sbin/dhclient-script; hence, I am definitely not looking at solving the issue either with /etc/dhclient.conf or /etc/dhclient-exit-hooks configuration file. BTW, resolver(5) / resolv.conf(5) does not mention the usage of /etc/dhclient-exit-hooks file to protect the earlier contents of /etc/resolv.conf file. Will put this issue in the freebsd-doc mailing list. With regards, Varuna Eudaemonic Systems Simple, Specific Insightful IT Consultants, Continued Education Systems Distribution +91-88-92-47-62-63 http://www.eudaemonicsystems.net http://enquiry.eudaemonicsystems.net -- This email is confidential, and may be legally privileged. If you are not the intended recipient, you must not use or disseminate this information in any format. If you have received this email in error, please do delete it along with copies of it existing in any other format, and notify the sender immediately. The sender of this email believes it is virus free, and does not accept any liability for any errors or omissions arising thereof. ___ 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
run_interrupt_driven_hooks: ... xpt_config delay
So, I have this problem, through all versions, from 8.* to 9.0 It happens when I build a custom kernel, which has ONLY 'device' lines, of machine's hardware. From 3 machines with that type of cutom kernels, only 1 suffers from this (and problem is gone, as soon as I revert to GENERIC) This delays boot procedure (which IS successfull, at the end) for at least twice: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config FACT 1 - GENERIC has something, which doesn't cause a problem! (reverting to it, resolves an issue) I've found this: http://www.freebsd.org/cgi/query-pr.cgi?pr=136327 But my custom kernels already don't have 'device spb' as well as GENERIC, so I doubt this is the cause. I've even done vice versa, added 'device spb' line to custom kernel, to no effect. So I doubt, above pr is relevant to me, but FACT 1. Which config line, GENERIC has that remedies my issue? Domagoj Smolčić ___ 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: run_interrupt_driven_hooks: ... xpt_config delay
On Wed, 2012-06-20 at 03:00 -0700, rank1see...@gmail.com wrote: From 3 machines with that type of cutom kernels, only 1 suffers from this (and problem is gone, as soon as I revert to GENERIC) Please post your custom kernel config somewhere so we can see what is different. Sean ___ 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
newbus / snd_hdspe(4) trouble
Hi. I have the problem with different behavior of snd_hdspe(4) sound card driver initialization. If I load the driver by hand using kldload everything works fine, but in case of loading driver at boot time (loader.conf) or compile in kernel the driver can't initialize propertly. The snd_hdspe(4) driver is designed to create a pcm child device per each pair of sound channels. The problem is that snd_hdspe loaded normally, but pcm child devices are not appears. hdspe_pcm_probe() in driver is not called at all. However snd_hdspe_pcm driver exists in kldstat -v after boot: 51 0x81377000 a2c8 snd_hdspe.ko (/boot/kernel/snd_hdspe.ko) Contains modules: Id Name 7 hdspe/snd_hdspe_pcm 6 pci/snd_hdspe and I have checked, device_add_child() returns not NULL. I played with MODULE_DEPEND as done in snd_hda(4) but no luck. What can I do to debug the problem? -Ruslan ___ 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
Interest in a Summer of Code in Space?
Hello; This year the European Space Agency will have it's second Summer of Code in Space: http://sophia.estec.esa.int/socis2012/ This may be a good opportunity to get FreeBSD in yet-another interesting field, plus one of our projects in the Ideas Page seems to be ideal to get some funding from them: http://wiki.freebsd.org/IdeasPage#SCPS.2C_Space_Communication_Protocol_Standards Just thought I would share this in case someone is interested :). Cheers, Pedro. ___ 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: sockstat.c
On 20 June 2012 16:48, Stanislav Zaharov root.vag...@gmail.com wrote: Hi all! I changed the sockstat.c, function display() - added a resize of fields, depending on the length of the data. Can I suggest you look at the resulting source code? no patch is attached. Can you resend or upload somewhere and give the url? -- Eitan Adler ___ 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: sockstat.c
Sorry, patch now as an attachment On Thu, Jun 21, 2012 at 3:55 AM, Eitan Adler li...@eitanadler.com wrote: On 20 June 2012 16:48, Stanislav Zaharov root.vag...@gmail.com wrote: Hi all! I changed the sockstat.c, function display() - added a resize of fields, depending on the length of the data. Can I suggest you look at the resulting source code? no patch is attached. Can you resend or upload somewhere and give the url? -- Eitan Adler -- Dear , Respectfully, Stanislav Putrya System network administrator LTD RMK Kovsh icq: 328585847 e-mail: root.vag...@gmail.com e-mail: vagner_ri...@bk.ru sockstat.patch Description: Binary data ___ 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
