Re: The rc.d mess strikes back

On Mar 1, 2009, at 9:18 PM, Boris Kochergin wrote:

> Garrett Cooper wrote:
>> On Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote:
>>
>>> In message: <E39D3873-3F36-467A-B225-347A088B68F9_at_gmail.com>
>>>           Garrett Cooper <yanefbsd_at_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
>>

>> 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

Thanks for the reminder to upload the other images.... here they are  
in their verbose glory:

http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=view&current=IMG_0033.jpg
http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=view&current=IMG_0034.jpg

And the interesting sections of my rc.conf:

ifconfig_msk0="DHCP"
defaultrouter="192.168.10.1"
hostname="orangebox.gateway.2wire.net"
nfs_client_enable="YES"
ntpdate_enable="YES"
ntpdate_flags="ntp.ucsd.edu"
rpcbind_enable="YES"
synchronous_dhclient="YES"

So the issue is again not with my interface, but the fact that  
registering dhcp sucks with my router (it's a lame 2wire hunk of AT&T  
junk), and it takes a while to register properly (5~10 seconds), and  
by the time the NFS mount line is reached, it's only been 2~3 seconds...

I realize the motivation for not having runlevels like Linux, but  
there should something such that mounting NFS filesystems doesn't  
cause rc to start from scratch because it's entirely unnecessary and  
it breaks a lot of assumptions with rc...

HTH,
-Garrett