Skip site navigation (1)Skip section navigation (2)
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
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&current=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>