Date: Mon, 02 Mar 2009 00:18:22 -0500 From: Boris Kochergin <spawk@acm.poly.edu> To: Garrett Cooper <yanefbsd@gmail.com> Cc: usb@freebsd.org, freebsd-current@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: The rc.d mess strikes back Message-ID: <49AB6C1E.1030808@acm.poly.edu> In-Reply-To: <2E9BD549-EF77-4F48-AB7E-C93AFC4BE387@gmail.com> References: <69F972E4-D7C1-47D8-8C83-A44062DB47E1@gmail.com> <6D5C9BFA-CCF4-4AEE-9688-23D66D594BC6@gmail.com> <E39D3873-3F36-467A-B225-347A088B68F9@gmail.com> <20090301.205017.1025328203.imp@bsdimp.com> <2E9BD549-EF77-4F48-AB7E-C93AFC4BE387@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Cooper wrote: > On Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote: > >> In message: <E39D3873-3F36-467A-B225-347A088B68F9@gmail.com> >> Garrett Cooper <yanefbsd@gmail.com> writes: >> : On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote: >> : >> : > On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: >> : > >> : >> On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: >> : >> >> : >>> Garrett Cooper wrote: >> : >>>> device ums # Mouse >> : >>> >> : >>> This is why you cannot kldload. Not sure about any functional >> : >>> regression. >> : >>> >> : >>> Sam >> : >> >> : >> Yeah, well that message was printed out by another process >> : >> altogether while loading up the kernel after the ata subsystem was >> : >> brought up, so something's getting confused and trying to kldload >> : >> by accident... I was just reproducing the message. >> : >> I'll provide more data to prove this claim when I can. >> : >> Thanks, >> : >> -Garrett >> : > >> : > Here's the picture from my iPhone: >> <http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=view¤t=IMG_0032.png >> >> : > >. I OBVIOUSLY didn't do the kldload... and because my /boot/ >> : > loader.conf doesn't contain ums_load="YES", I'm really curious who >> : > the actual culprit is in rc.d land... >> : > I used to do WITHOUT_MODULES=* to not build modules, but I'm >> trying >> : > to move away from that mentality for some things like snd_emu10kx, >> : > but obviously there's a conflict somewhere for ums; hopefully it's >> : > merely cosmetic... >> : > Thanks, >> : > -Garrett >> : >> : Ok, found the culprit. It turns out moused is being called from >> : devd... this is all probably related to the startup mess I reported 2 >> : weeks ago with my NIC. I'm seeing a lot of additional problems in >> : terms of keeping track of daemons; for instance syslogd is getting >> : started up twice, but the first instance isn't recording a PID and the >> : second one is dying because the first one is bound to the address. >> : Agh... >> >> I didn't think that moused loaded anything. >> >> And what do extra nics have to do with this? I think you are >> confusing multiple problems... >> >> : Could we just unwind this rc.d mess? It seems to be causing issues >> : and wasn't very thoroughly tested before commit. >> >> This is a little to vague to be actionable. Do you have specific >> instances? Do you have rcorder output? Etc... >> >> Warner > > For whatever reason the NFS filemounts not coming up forces rc.d > to restart from a square one (because it enters maintenance mode), > which nukes PID files in /var/run (I'm assuming) via the cleanvar > service, and causes devd and syslogd to be started twice, which in > turn causes that message to be printed out on the console. devd's rc > script is just smart enough to recognize that there's a PID already > running on the system, and thus it doesn't try to start more than > once, but syslogd's is braindead (is there really a point to running > multiple instances of syslogd?) and thus it tries to start up the > service twice. > I'm understand why devd attempts to probe and install ums in the > kernel's namespace if it already exists... but I'm unhappy with the > fact that even though I set moused_enable=NO in rc.conf, moused still > doesn't honor that option ;(... > -Garrett > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" With regard to NFS breaking your boot process, I have run into the same thing recently, but it was my fault. Your screenshot omits the potentially-interesting information, if the problem is the same. In my case, /etc/rc.d/* was out of sync with /etc/network.subr. /etc/rc.d/netif, which handles the ifconfig_* lines in rc.conf, has references to an ifn_start() function in /etc/network.subr, so interfaces configured in rc.conf never came up. -Boris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49AB6C1E.1030808>