The rc.d mess strikes back
Boris Kochergin
spawk at acm.poly.edu
Sun Mar 1 21:46:38 PST 2009
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¤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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe at 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
More information about the freebsd-current
mailing list