Re: du and df don't agree
On Mon, Nov 10, 2008 at 11:21:11PM +0700, Eugene Grosbein typed: > On Mon, Nov 10, 2008 at 11:01:00AM -0500, Stephen Clark wrote: > > > Why would du show 630k used by /tmp while df show 161M used > > by /tmp? > > > > I have run fstat /tmp and can't find any files that are using > > the space that df is claiming as being used. > > You need lsof +aL1 /tmp to see an answer. Please don't advise people to install third party apps (lsof) where base system tools (fstat) can do the job. Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic in kevent
Hi
One of my DL360G5 boxes running 7.0 had a panic this night:
jb-2 ~$ uname -rsv
FreeBSD 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #2: Thu Sep 4 10:49:27
CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DL360G5
The config is a GENERIC with some pf, IPSEC and ALTQ stuff enabled.
jb-2 /usr/obj/usr/src/sys/DL360G5# kgdb kernel.debug /var/crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/
libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "amd64-marcel-freebsd".
Unread portion of the kernel message buffer:
panic: page fault
cpuid = 1
Uptime: 40d22h42m5s
Physical memory: 10225 MB
Dumping 867 MB: 852 836 820 804 788 772 756 740 724 708 692 676 660
644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388
372 356
#0 doadump () at pcpu.h:194
194 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) where
#0 doadump () at pcpu.h:194
#1 0x0004 in ?? ()
#2 0x804bb259 in boot (howto=260) at /usr/src/sys/kern/
kern_shutdown.c:409
#3 0x804bb65d in panic (fmt=0x104 bounds>) at /usr/src/sys/kern/kern_shutdown.c:563
#4 0x8079ec84 in trap_fatal (frame=0xff01b33229f0,
eva=18446742984664492240) at /usr/src/sys/amd64/amd64/trap.c:724
#5 0x8079f055 in trap_pfault (frame=0xb6337780,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641
#6 0x8079f998 in trap (frame=0xb6337780) at /usr/src/
sys/amd64/amd64/trap.c:410
#7 0x8078560e in calltrap () at /usr/src/sys/amd64/amd64/
exception.S:169
#8 0x80494b0b in knlist_remove_kq (knl=0xff0114407748,
kn=0xff0054f5fc30, knlislocked=0, kqislocked=0)
at /usr/src/sys/kern/kern_event.c:1615
#9 0x80495f58 in kqueue_register (kq=Variable "kq" is not
available.
) at /usr/src/sys/kern/kern_event.c:956
#10 0x804962f3 in kern_kevent (td=0xff01b33229f0,
fd=Variable "fd" is not available.
) at /usr/src/sys/kern/kern_event.c:673
#11 0x80496ca5 in kevent (td=0xff01b33229f0,
uap=0xb6337be0) at /usr/src/sys/kern/kern_event.c:594
#12 0x8079f2d7 in syscall (frame=0xb6337c70) at /usr/
src/sys/amd64/amd64/trap.c:852
#13 0x8078581b in Xfast_syscall () at /usr/src/sys/amd64/amd64/
exception.S:290
#14 0x10999ccc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Please let me know if I can help with anything else. Is there any way
to know which app caused this?
I Did some googling with only one or two similar crashes as result,
although the hits didn't give much..
I've never had this crash before.
Thanks
--
Johan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du and df don't agree
Ruben de Groot wrote: On Mon, Nov 10, 2008 at 11:21:11PM +0700, Eugene Grosbein typed: On Mon, Nov 10, 2008 at 11:01:00AM -0500, Stephen Clark wrote: Why would du show 630k used by /tmp while df show 161M used by /tmp? I have run fstat /tmp and can't find any files that are using the space that df is claiming as being used. You need lsof +aL1 /tmp to see an answer. Please don't advise people to install third party apps (lsof) where base system tools (fstat) can do the job. Why not? This is one of the ways I pick up on all kinds of nice tools I've not heard of before. And it is not like this is swamping the list with of topic questions. You might have redirected the question to questions@ OTOH: The initial question indicated that fstat did not give the info wanted. Your info does not help, because you told him to use fstat, but forgot to mention HOW. So he is in no way any wiser after your answer. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
on 08/11/2008 14:31 Volker said the following: > Andriy, > > On 12/23/-58 20:59, Andriy Gapon wrote: >> I have a quite strange problem. >> This is with 7-BETA amd64. > > Did it work with earlier versions? Can't say, this is a new machine, FreeBSD took its virginity :-) >> All of USB is out of kernel and is loaded via modules. >> BIOS has "Legacy USB" enabled. >> I have only a USB keyboard, no PS/2 port. > > Can you check BIOS settings for EHCI handover? No such settings. > If the BIOS does not have handover enabled, it may disable legacy > support after a timeout, which is often bad. IMO this is the same with > booting off USB drives but every BIOS handles that different. This doesn't seem to be the case. The behavior is quite random, sometimes I can work at loader prompt for may minutes, sometimes keyboard is dead after a few seconds. Also, I think USB keyboard is handled by UHCI, not EHCI in my case, but I am not sure if this matters. My guess is that Legacy support should work until OS explicitly takes over by using special procedure (this should be done for UHCI as well). BTW, it seems that our UHCI take-over code is far more simple than what MS described here: http://www.microsoft.com/whdc/archive/usbhost.mspx#EQHAC Anyway, this happens after loader is done. >> The keyboard works file in BIOS and for selecting boot device in boot0 >> menu. It also works in loader menu. If in the menu I select to go to >> loader prompt then it works for about 5 seconds and then "dies" - no >> reaction to key presses, no led change, nothing. >> I haven't actually verified if the keyboard would still work if I stayed >> in loader menu for longer than ~10 seconds. >> >> This doesn't happen if USB is built into kernel. > > That sound strange. I have no idea why that might work (or I'm totally > wrong with my handover theory). I was incorrect about the above, I have already seen it happening both ways. >> Weird... > > Yes, sounds like or it's probably easily explainable ;) -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
The report from lighttpd looks fine:
cache.cached-itmes: 98293
cache.hitrate(%): 96
cache.memory-inuse(KB): 6143
fastcgi.active-requests: 16
fastcgi.backend.0.0.connected: 419008
fastcgi.backend.0.0.died: 0
fastcgi.backend.0.0.disabled: 0
fastcgi.backend.0.0.load: 16
fastcgi.backend.0.0.overloaded: 0
fastcgi.backend.0.load: 17
fastcgi.requests: 419008
But at this moment:
web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort |
uniq -c | sort -n
1 biord
1 wait
2 -
16 sbwait
29 accept
web4# ps alx | grep php-cgi | grep -v grep | grep sbwait
65534 61392 61384 1 4 -15 182328 69312 sbwait I
> You can try taking look to lighttpd status and fcgi processes status
> like this:
> server.modules += ( "mod_status" )
> status.status-url = "/server-status"
> status.statistics-url = "/sstatus1"
>
> status.statistics-url gives info for each fastcgi like this:
>
> fastcgi.active-requests: 0
> fastcgi.backend.backend1.0.connected: 12493970
> fastcgi.backend.backend1.0.died: 0
> fastcgi.backend.backend1.0.disabled: 0
> fastcgi.backend.backend1.0.load: 0
> fastcgi.backend.backend1.0.overloaded: 0
> fastcgi.backend.backend1.load: 1
> fastcgi.requests: 19479062
>
>
> etc... read what each means on lighttpd site...
> pls tell what caused this, it'd be very interesting to me!
>
> cheers,
> valqk.
>
> Ken Chen wrote:
> > I capture something.
> >
> > Please check the PID 57776. It's CPU time never change since my previous
> > mail here.
> >
> > web4# ps alx | grep php-cgi | grep -v grep | grep sbwait
> > 65534 57776 47240 0 4 0 182328 84984 sbwait I ??2:02.12
> > /usr/local/bin/php-cgi
> > 65534 57801 47240 0 4 0 182328 82408 sbwait I ??0:19.97
> > /usr/local/bin/php-cgi
> > 65534 57809 47240 0 4 0 182328 84096 sbwait I ??1:12.03
> > /usr/local/bin/php-cgi
> > 65534 57823 47240 0 4 0 182328 84492 sbwait I ??2:04.21
> > /usr/local/bin/php-cgi
> > 65534 57833 47240 0 4 0 183352 83316 sbwait I ??0:28.62
> > /usr/local/bin/php-cgi
> > 65534 57866 47240 0 4 0 182328 79952 sbwait I ??0:05.92
> > /usr/local/bin/php-cgi
> > 65534 57870 47240 0 4 0 182328 83184 sbwait I ??0:56.83
> > /usr/local/bin/php-cgi
> > 65534 57871 47240 0 4 0 182328 83388 sbwait I ??0:54.96
> > /usr/local/bin/php-cgi
> > 65534 57891 47240 0 4 0 182328 84436 sbwait I ??1:58.32
> > /usr/local/bin/php-cgi
> > 65534 57925 47240 0 4 0 182328 84380 sbwait I ??2:03.53
> > /usr/local/bin/php-cgi
> > 65534 65944 47240 0 4 0 182328 84184 sbwait I ??0:39.97
> > /usr/local/bin/php-cgi
> > 65534 65952 47240 0 4 0 182328 84408 sbwait I ??0:21.37
> > /usr/local/bin/php-cgi
> > 65534 66007 47240 0 4 0 183352 90960 sbwait I ??1:16.81
> > /usr/local/bin/php-cgi
> > 65534 66014 47240 5 4 0 182328 92748 sbwait S ??
MFC Request
Is it possible to have traceroute MFC'd for 7.1? I would like to have -a and -A switchs (ASN Path mapping) available. Thank you :) -- Patrick Tracanelli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
On Tue, Nov 11, 2008 at 10:09:38PM +0800, Ken Chen wrote:
> I think the parent php-cgi are very health. I have tried:
>
> There are total 49 php-cgi processes are running or frozen, the '1 wait' is
> parent .
>
> web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
> -c | sort -n
>1 biowr
>1 wait
> 15 sbwait
> 32 accept
>
> Kill one of frozen php-cgi processes.
>
> web4# kill -9 61392
>
> Check again the amount of php-cgi processes, there are still 49 php-cgi
> procerss.
>
> web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
> -c | sort -n
>1 biord
>1 bo_wwa
>1 wait
>4 -
> 17 sbwait
> 25 accept
I would recommend you try the lighttpd and fastcgi mailing lists at this
point.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic in kevent
On Tue, Nov 11, 2008 at 09:49:26AM +0100, Johan Str?m wrote:
> Hi
> One of my DL360G5 boxes running 7.0 had a panic this night:
>
> jb-2 ~$ uname -rsv
> FreeBSD 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #2: Thu Sep 4 10:49:27
> CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DL360G5
>
> The config is a GENERIC with some pf, IPSEC and ALTQ stuff enabled.
>
> jb-2 /usr/obj/usr/src/sys/DL360G5# kgdb kernel.debug /var/crash/vmcore.0
> [GDB will not be able to debug user-mode threads: /usr/lib/
> libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "amd64-marcel-freebsd".
>
> Unread portion of the kernel message buffer:
>
> panic: page fault
> cpuid = 1
> Uptime: 40d22h42m5s
> Physical memory: 10225 MB
> Dumping 867 MB: 852 836 820 804 788 772 756 740 724 708 692 676 660
> 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388
> 372 356
>
> #0 doadump () at pcpu.h:194
> 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) where
> #0 doadump () at pcpu.h:194
> #1 0x0004 in ?? ()
> #2 0x804bb259 in boot (howto=260) at /usr/src/sys/kern/
> kern_shutdown.c:409
> #3 0x804bb65d in panic (fmt=0x104 bounds>) at /usr/src/sys/kern/kern_shutdown.c:563
> #4 0x8079ec84 in trap_fatal (frame=0xff01b33229f0,
> eva=18446742984664492240) at /usr/src/sys/amd64/amd64/trap.c:724
> #5 0x8079f055 in trap_pfault (frame=0xb6337780,
> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641
> #6 0x8079f998 in trap (frame=0xb6337780) at /usr/src/
> sys/amd64/amd64/trap.c:410
> #7 0x8078560e in calltrap () at /usr/src/sys/amd64/amd64/
> exception.S:169
> #8 0x80494b0b in knlist_remove_kq (knl=0xff0114407748,
> kn=0xff0054f5fc30, knlislocked=0, kqislocked=0)
> at /usr/src/sys/kern/kern_event.c:1615
> #9 0x80495f58 in kqueue_register (kq=Variable "kq" is not
> available.
> ) at /usr/src/sys/kern/kern_event.c:956
> #10 0x804962f3 in kern_kevent (td=0xff01b33229f0,
> fd=Variable "fd" is not available.
> ) at /usr/src/sys/kern/kern_event.c:673
> #11 0x80496ca5 in kevent (td=0xff01b33229f0,
> uap=0xb6337be0) at /usr/src/sys/kern/kern_event.c:594
> #12 0x8079f2d7 in syscall (frame=0xb6337c70) at /usr/
> src/sys/amd64/amd64/trap.c:852
> #13 0x8078581b in Xfast_syscall () at /usr/src/sys/amd64/amd64/
> exception.S:290
> #14 0x10999ccc in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
>
>
> Please let me know if I can help with anything else. Is there any way
> to know which app caused this?
> I Did some googling with only one or two similar crashes as result,
> although the hits didn't give much..
> I've never had this crash before.
There is very high chances that the problem fixed in the 7.1.
Unless it is easily reproducable in your settings, there is no
easy way to confirm this.
You can do "info threads" in the kgdb to overview processes on the
crashed system. The thread that was on the CPU during the crash will
be marked by star.
pgpQaRlFh8Hz3.pgp
Description: PGP signature
Re: usb keyboard dying at loader prompt
On Tue, Nov 11, 2008 at 5:14 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: > on 08/11/2008 14:31 Volker said the following: >> Andriy, >> >> On 12/23/-58 20:59, Andriy Gapon wrote: >>> I have a quite strange problem. >>> This is with 7-BETA amd64. >> >> Did it work with earlier versions? > > Can't say, this is a new machine, FreeBSD took its virginity :-) > >>> All of USB is out of kernel and is loaded via modules. >>> BIOS has "Legacy USB" enabled. >>> I have only a USB keyboard, no PS/2 port. >> >> Can you check BIOS settings for EHCI handover? > > No such settings. > >> If the BIOS does not have handover enabled, it may disable legacy >> support after a timeout, which is often bad. IMO this is the same with >> booting off USB drives but every BIOS handles that different. > > This doesn't seem to be the case. The behavior is quite random, > sometimes I can work at loader prompt for may minutes, sometimes > keyboard is dead after a few seconds. > Also, I think USB keyboard is handled by UHCI, not EHCI in my case, but > I am not sure if this matters. My guess is that Legacy support should > work until OS explicitly takes over by using special procedure (this > should be done for UHCI as well). > > BTW, it seems that our UHCI take-over code is far more simple than what > MS described here: > http://www.microsoft.com/whdc/archive/usbhost.mspx#EQHAC > > Anyway, this happens after loader is done. > >>> The keyboard works file in BIOS and for selecting boot device in boot0 >>> menu. It also works in loader menu. If in the menu I select to go to >>> loader prompt then it works for about 5 seconds and then "dies" - no >>> reaction to key presses, no led change, nothing. >>> I haven't actually verified if the keyboard would still work if I stayed >>> in loader menu for longer than ~10 seconds. >>> >>> This doesn't happen if USB is built into kernel. >> >> That sound strange. I have no idea why that might work (or I'm totally >> wrong with my handover theory). > > I was incorrect about the above, I have already seen it happening both ways. > >>> Weird... >> >> Yes, sounds like or it's probably easily explainable ;) > > > -- > Andriy Gapon > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Some bioses have a list of MBR partition id's and use that to determine what to do with the USB keyboard. One of my ol older amd64 motherboards worked but would always disable the usb keyboard right as loader started. I discovered the following: * If I put the freebsd bootblocks and loader on a floppy drive (no MBR), then the bios did not turn off the keyboard. It always continued to work for loader. * If i hacked the boot bootblocks and loader and kernel to recognize different MBR slice id nubmers as "ours", then changing the freebsd MBR to be "msdos" or "linux" also worked for that BIOS. It would no longer turn off the USB keyboard. I don't recall which Id number I used instead of 165 - it was about 4 years ago. * There were other consequences of using the partition ID hack - I think I remember it turning off the apic for msdos mode. Your problems may be different, but mine were caused by a BIOS whitelist of MBR partition id's. What a stupid problem. On that motherboard I ended up taking the path of least resistance and using the PS/2 adapter plug on the keyboard. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
Thank Jeremy, I will try.
2008/11/12 Jeremy Chadwick <[EMAIL PROTECTED]>
> On Tue, Nov 11, 2008 at 10:09:38PM +0800, Ken Chen wrote:
> > I think the parent php-cgi are very health. I have tried:
> >
> > There are total 49 php-cgi processes are running or frozen, the '1 wait'
> is
> > parent .
> >
> > web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort |
> uniq
> > -c | sort -n
> >1 biowr
> >1 wait
> > 15 sbwait
> > 32 accept
> >
> > Kill one of frozen php-cgi processes.
> >
> > web4# kill -9 61392
> >
> > Check again the amount of php-cgi processes, there are still 49 php-cgi
> > procerss.
> >
> > web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort |
> uniq
> > -c | sort -n
> >1 biord
> >1 bo_wwa
> >1 wait
> >4 -
> > 17 sbwait
> > 25 accept
>
> I would recommend you try the lighttpd and fastcgi mailing lists at this
> point.
>
> --
> | Jeremy Chadwickjdc at parodius.com |
> | Parodius Networking http://www.parodius.com/ |
> | UNIX Systems Administrator Mountain View, CA, USA |
> | Making life hard for others since 1977. PGP: 4BD6C0CB |
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
/usr/local/etc/rc.d getting run twice
Greetings, I have new freshly installed servers of FreeBSD 6.3. We started our migration before 6.4 was released. Anyway we have some custom tools that we have built startup scripts for and placed them into /usr/local/etc/rc.d. However the problem is that these tools get called twice to startup. Thus leaving us with two instances of the tools running. I've read a thread similar to this question in the mailing list archive however it had to do with upgrading and didn't seem to apply to my issue. I've added a buch of logic to the script to try to determine if the tool is running or not, but that seems like band aiding the issue instead of fixing the problem. Any advice? -Geoff Sweet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: MFC Request
On Tue, 2008-11-11 at 13:06 -0200, Patrick Tracanelli wrote: > Is it possible to have traceroute MFC'd for 7.1? I would like to have -a I second that request. I'm prepared to bribe someone as well. ~BAS > and -A switchs (ASN Path mapping) available. Thank you :) > -- Brian A. Seklecki <[EMAIL PROTECTED]> Collaborative Fusion, Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/local/etc/rc.d getting run twice
Ah, indeed that seems to be the problem. Thank you, I may never have
spotted that on my own.
-Geoff Sweet
On Tue, 2008-11-11 at 11:21 -0800, David Wolfskill wrote:
> On Tue, Nov 11, 2008 at 10:45:04AM -0800, Geoff Sweet wrote:
> > Greetings, I have new freshly installed servers of FreeBSD 6.3
> > Any advice?
>
> Check the value of local_startup in /etc/{defaults/,}rc.conf.
>
> In 6.3, I believe the default was
>
> /usr/local/etc/rc.d /usr/X11R6/etc/rc.d
>
> but you may find that /usr/X11R6 has become a symlink to /usr/local
> (after upgrading X11).
>
> If it is, you can avoid the problem by placing
>
> local_startup="/usr/local/etc/rc.d"
>
> in /etc/rc.conf.
>
> Peace,
> david
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/local/etc/rc.d getting run twice
On Tue, Nov 11, 2008 at 10:45:04AM -0800, Geoff Sweet wrote:
> Greetings, I have new freshly installed servers of FreeBSD 6.3
> Any advice?
Check the value of local_startup in /etc/{defaults/,}rc.conf.
In 6.3, I believe the default was
/usr/local/etc/rc.d /usr/X11R6/etc/rc.d
but you may find that /usr/X11R6 has become a symlink to /usr/local
(after upgrading X11).
If it is, you can avoid the problem by placing
local_startup="/usr/local/etc/rc.d"
in /etc/rc.conf.
Peace,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpuYW9t1cwn6.pgp
Description: PGP signature
Discussing non BSD tools on Stable (Was: Re: du and df don't agree)
Ruben de Groot wrote: You need lsof +aL1 /tmp to see an answer. Please don't advise people to install third party apps (lsof) where base system tools (fstat) can do the job. Why not? Because it gives the impression the base system is incomplete, which it is not, at least not in this situation. The wording "you need lsof" is plain wrong. Perhaps the wording is chosen to be too strong. But This is one of the ways I pick up on all kinds of nice tools I've not heard of before. And it is not like this is swamping the list with of topic questions. Difference of opinion; I prefer to use FreeBSD tools before falling back to 3rd party tools, no matter how nice. Shure, so do I. But then base and ports are just like one very large candy store, and there are too many tools to know about. You might have redirected the question to questions@ > I don't see the point. Why didn't you redirect it? 1) You made it sound like it is an obvious question with an even more obvious answer. And normally these go to questions@ 2) The reason for this is on the Unix FAQ, not shure it has this answer with it. 3) Because I would not know the answer to the question asked, And what I should have done is change the subject with the previous posting. OTOH The initial question indicated that fstat did not give the info wanted. Your info does not help, because you told him to use fstat, but forgot to mention HOW. So he is in no way any wiser after your answer. Yes, my bad. But he allready found the answer himself (using fstat -f I guess). You've at least now given me a reason to look at another base tool :) FAIC this is the last we post on this, and get back to using/hacking FreeBSD. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
On 11/11/08 19:55, Peter Wemm wrote: > ... > * There were other consequences of using the partition ID hack - I > think I remember it turning off the apic for msdos mode. > > Your problems may be different, but mine were caused by a BIOS > whitelist of MBR partition id's. What a stupid problem. On that > motherboard I ended up taking the path of least resistance and using > the PS/2 adapter plug on the keyboard. Peter, very interesting what you've found. That reminds me on some investigations I did as I was hunting USB boot device problems. Some BIOSes do not check the partition (slice) ID but are looking for a file system magic. If a FAT filesystem is detected, the BIOS does some stupid things (like ignoring the active partition flag and booting the FAT slice no matter what you've flagged active). Just an example and off-topic to Andriy's keyboard problem. But when combining that with your findings, it may still be a thing to check for... ;) Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/local/etc/rc.d getting run twice
On Tue, 11 Nov 2008 at 13:45 -, Geoff Sweet wrote: > Greetings, I have new freshly installed servers of FreeBSD 6.3. We > started our migration before 6.4 was released. Anyway we have some > custom tools that we have built startup scripts for and placed them > into /usr/local/etc/rc.d. However the problem is that these tools get > called twice to startup. Thus leaving us with two instances of the > tools running. You probably need the following line added to /etc/rc.conf: local_startup="/usr/local/etc/rc.d" The defaults in /etc/defaults/rc.conf still try to run startup scripts in /usr/local/etc/rc.d and /usr/X11R6/etc/rc.d, however these are probably the same location via a /usr/X11R6 link. One of the X ports attempts to add this, but I've seen cases where it doesn't get added. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
On Tue, Nov 11, 2008 at 12:09 PM, Volker <[EMAIL PROTECTED]> wrote: > On 11/11/08 19:55, Peter Wemm wrote: >> ... >> * There were other consequences of using the partition ID hack - I >> think I remember it turning off the apic for msdos mode. >> >> Your problems may be different, but mine were caused by a BIOS >> whitelist of MBR partition id's. What a stupid problem. On that >> motherboard I ended up taking the path of least resistance and using >> the PS/2 adapter plug on the keyboard. > > Peter, > > very interesting what you've found. That reminds me on some > investigations I did as I was hunting USB boot device problems. > > Some BIOSes do not check the partition (slice) ID but are looking for a > file system magic. If a FAT filesystem is detected, the BIOS does some > stupid things (like ignoring the active partition flag and booting the > FAT slice no matter what you've flagged active). Just an example and > off-topic to Andriy's keyboard problem. > > But when combining that with your findings, it may still be a thing to > check for... ;) > > Volker I have long since stopped being surprised by what bios writers come up with. Or should I say "windows boot loader" instead of bios, because that is what it seems to have degenerated into these days. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
On Tue, Nov 11, 2008 at 09:09:00PM +0100, Volker wrote: > On 11/11/08 19:55, Peter Wemm wrote: > > ... > > * There were other consequences of using the partition ID hack - I > > think I remember it turning off the apic for msdos mode. > > > > Your problems may be different, but mine were caused by a BIOS > > whitelist of MBR partition id's. What a stupid problem. On that > > motherboard I ended up taking the path of least resistance and using > > the PS/2 adapter plug on the keyboard. > > Peter, > > very interesting what you've found. That reminds me on some > investigations I did as I was hunting USB boot device problems. > > Some BIOSes do not check the partition (slice) ID but are looking for a > file system magic. If a FAT filesystem is detected, the BIOS does some > stupid things (like ignoring the active partition flag and booting the > FAT slice no matter what you've flagged active). Just an example and > off-topic to Andriy's keyboard problem. > > But when combining that with your findings, it may still be a thing to > check for... ;) Since you folks in this thread have some pretty good experience with BIOS behaviour and bootloader/filesystem stuff, could I ask that someone take a look at something I posted at over on -fs? I'm out of ideas at this point. http://lists.freebsd.org/pipermail/freebsd-fs/2008-November/005317.html Danke! -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
on 06/11/2008 14:34 Andriy Gapon said the following: > I have a quite strange problem. > This is with 7-BETA amd64. > All of USB is out of kernel and is loaded via modules. > BIOS has "Legacy USB" enabled. > I have only a USB keyboard, no PS/2 port. > > The keyboard works file in BIOS and for selecting boot device in boot0 > menu. It also works in loader menu. If in the menu I select to go to > loader prompt then it works for about 5 seconds and then "dies" - no > reaction to key presses, no led change, nothing. > I haven't actually verified if the keyboard would still work if I stayed > in loader menu for longer than ~10 seconds. > > This doesn't happen if USB is built into kernel. > > Weird... I did more experimentation and the behavior seems to be quite random - sometimes keyboard works ok for long time in all places, sometimes it stops working after some period of time, sometimes it doesn't work from the start and couple of times I experienced boot process going astray. Not sure what stage that was, there were endless messages spewed on the screen very fast, I couldn't read them. This leads me to the following "crazy" question - is it possible that our boot chain corrupts some vital BIOS memory? I think loader would be a primary suspect. I am not sure of anything, but a wild guess is that RAM where BIOS stores some USB-related stuff gets corrupted. Maybe it's overwritten when kernel and modules are loaded... -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usb keyboard dying at loader prompt
Am Tue, 11 Nov 2008 10:55:45 -0800 schrieb "Peter Wemm" <[EMAIL PROTECTED]>: > Some bioses have a list of MBR partition id's and use that to > determine what to do with the USB keyboard. One of my ol older amd64 > motherboards worked but would always disable the usb keyboard right as > loader started. I discovered the following: > * If I put the freebsd bootblocks and loader on a floppy drive (no > MBR), then the bios did not turn off the keyboard. It always > continued to work for loader. > * If i hacked the boot bootblocks and loader and kernel to recognize > different MBR slice id nubmers as "ours", then changing the freebsd > MBR to be "msdos" or "linux" also worked for that BIOS. It would no > longer turn off the USB keyboard. I don't recall which Id number I > used instead of 165 - it was about 4 years ago. > * There were other consequences of using the partition ID hack - I > think I remember it turning off the apic for msdos mode. > > Your problems may be different, but mine were caused by a BIOS > whitelist of MBR partition id's. What a stupid problem. On that > motherboard I ended up taking the path of least resistance and using > the PS/2 adapter plug on the keyboard. Hello, I want to add some information about USB problems which occur for me very frequently. I have found out that most of the problems are related to Gigabyte mainboards. I have 2 of them now. One is "EP35C-DS3R". With this mainboard sometimes my USB keyboard and USB mouse stop working (the power is simply off). I can reattach them and they both power up again. The second mainboard is "EP45-DS3R". Here the problem is even worse. The keyboard and mouse (both USB) lose power as soon as FreeBSD scans the USB controllers. Here, I can also reattach the devices and they are usable again. One further hint: it seems Vista (64 bit version) has the same problem with this EP45-DS3R mainboard. After it boots into the login screen, I have to reattach the devices to use them. The mainboard is not broken, I have tried 3 so far and all have these strange effects. And now... I want to remind you that I have already posted here about (same) USB problems on my laptop (Lenovo Thinkpad T60p). Sometimes I have to reattach my keyboard there, too. Of course, this is not Gigabyte here, but the weird behaviour ressembles the one above. -- Martin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du and df don't agree
On Tue, Nov 11, 2008 at 10:22:42AM +0100, Willem Jan Withagen typed: > Ruben de Groot wrote: > >On Mon, Nov 10, 2008 at 11:21:11PM +0700, Eugene Grosbein typed: > >>On Mon, Nov 10, 2008 at 11:01:00AM -0500, Stephen Clark wrote: > >> > >>>Why would du show 630k used by /tmp while df show 161M used > >>>by /tmp? > >>> > >>>I have run fstat /tmp and can't find any files that are using > >>>the space that df is claiming as being used. > >>You need lsof +aL1 /tmp to see an answer. > > > >Please don't advise people to install third party apps (lsof) where > >base system tools (fstat) can do the job. > > Why not? Because it gives the impression the base system is incomplete, which it is not, at least not in this situation. The wording "you need lsof" is plain wrong. > This is one of the ways I pick up on all kinds of nice tools I've not heard > of before. And it is not like this is swamping the list with of topic > questions. Difference of opinion; I prefer to use FreeBSD tools before falling back to 3rd party tools, no matter how nice. > You might have redirected the question to questions@ I don't see the point. Why didn't you redirect it? > OTOH > The initial question indicated that fstat did not give the info wanted. > Your info does not help, because you told him to use fstat, but forgot to > mention HOW. So he is in no way any wiser after your answer. Yes, my bad. But he allready found the answer himself (using fstat -f I guess). Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: du and df don't agree
On Tue, 11 Nov 2008 11:55:30 +0100, Ruben de Groot <[EMAIL PROTECTED]> wrote: > On Tue, Nov 11, 2008 at 10:22:42AM +0100, Willem Jan Withagen typed: >> Ruben de Groot wrote: >> >On Mon, Nov 10, 2008 at 11:21:11PM +0700, Eugene Grosbein typed: >> >>On Mon, Nov 10, 2008 at 11:01:00AM -0500, Stephen Clark wrote: >> >> >> >>>Why would du show 630k used by /tmp while df show 161M used >> >>>by /tmp? >> >>> >> >>>I have run fstat /tmp and can't find any files that are using >> >>>the space that df is claiming as being used. >> >>You need lsof +aL1 /tmp to see an answer. >> > >> >Please don't advise people to install third party apps (lsof) where >> >base system tools (fstat) can do the job. >> >> Why not? > > Because it gives the impression the base system is incomplete, which it is > not, > at least not in this situation. The wording "you need lsof" is plain > wrong. > What about proposing both? As in use fstat from BASE or use lsof from ports. IMO it's good to know that there are several tools which solves your problem. As an example from real world. I love using "sockstat -4" on FreeBSD, but I'm annoyed that it doesn't exist in OpenBSD and it doesn't exist in Debian either. So I'm used to use "netstat -tulpen" on Debian, but that won't work on FreeBSD. Anyway, since I know both ways, I find my way in both systems. Summary: Good to know alternatives. ./Marian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php-cgi frozen with sbwait when SMP enable
I think the parent php-cgi are very health. I have tried:
There are total 49 php-cgi processes are running or frozen, the '1 wait' is
parent .
web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
-c | sort -n
1 biowr
1 wait
15 sbwait
32 accept
Kill one of frozen php-cgi processes.
web4# kill -9 61392
Check again the amount of php-cgi processes, there are still 49 php-cgi
procerss.
web4# ps alx | grep php-cgi | grep -v grep | awk '{print $9}' | sort | uniq
-c | sort -n
1 biord
1 bo_wwa
1 wait
4 -
17 sbwait
25 accept
2008/11/10 Anton - Valqk <[EMAIL PROTECTED]>
> Oh, just saw that, this could be caused by dead parent php-cgi processes
> (just a guess).
> I used to run lighttpd with span-fcgi executable and it happens very
> often to have dead parents (of php-cgi childs) that must be killed by
> killall php-cgi (eg. restart _ALL_ php-cgi processes, pretty stupid!!!
> but if you have dead parent you can't know which childs to kill)...
> If you run your php-cgi processes just from the lighttpd(and lighttpd
> manages php-cgi processes) try running it with fcgi-spawn and write a
> script to check parents of the php-cgi backends and you'll see if that's
> the cause of having 'hang' phps :(
>
> pls tell me what is it. I'm interested!
>
> cheers,
> valqk.
> Ken Chen wrote:
> > Hi Jeremy,
> >
> > A health FastCGI process have a lifetime, so the PIDs of all php-cgi
> > processes should in a short range.
> >
> > There are some 'php-cgi' fall in 'sbwait' state, and stay there forever.
> The
> > frozen 'php-cgi' can't accept new request, so never retire.
> >
> > Please forgive my poor English.
> >
> > 2008/11/7 Jeremy Chadwick <[EMAIL PROTECTED]>
> >
> >
> >> On Fri, Nov 07, 2008 at 07:29:37PM +0800, Ken Chen wrote:
> >>
> >>> Hello,
> >>>
> >>> I have 4 web servers with lighttpd to serve one web site with DNS load
> >>> sharing. On the 2 SMP-enable web servers, there will be many php-cgi
> >>>
> >> frozen
> >>
> >>> in 'sbwait' state every day. It means the php-cgi stay in 'sbwait'
> state,
> >>> and never be back to 'accept' or other state. If I restart them, there
> >>>
> >> will
> >>
> >>> be frozen php-cgi appear some hours later.
> >>>
> >>> There is no problem on the other single CPU web servers which running
> >>>
> >> same
> >>
> >>> php scripts and same configuration and version of PHP.
> >>>
> >>> Why and any solution?
> >>>
> >> I'm not understanding what the problem is (and I've seen the output you
> >> provided later in the thread). Are you stating the problem is that you
> >> see many php-cgi processes? Or are you worried they're not doing
> >> anything? Does the website function, lock up, or anything like that?
> >> If not, what's the issue? :-)
> >>
> >> --
> >> | Jeremy Chadwickjdc at parodius.com |
> >> | Parodius Networking http://www.parodius.com/ |
> >> | UNIX Systems Administrator Mountain View, CA, USA |
> >> | Making life hard for others since 1977. PGP: 4BD6C0CB |
> >>
> >>
> >>
> > ___
> > freebsd-stable@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]
> "
> >
> >
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
