Re: Some processes stay active after killing its PID
On Tuesday 27 November 2007 03:14 pm, Jeremy Chadwick wrote:
On Tue, Nov 27, 2007 at 08:59:06PM +0100, Roland Smith wrote:
On Tue, Nov 27, 2007 at 01:24:56PM -0600, Stephen Montgomery-Smith
wrote:
On Tue, 27 Nov 2007, Honza Holakovsky wrote:
Well, didn't know that, /bin/kill -9 wdfs_PID works, great
Thanks a lot, after your advice I read an article about csh
built-in commands, never heard of it from any fbsd handbook...
I am completely baffled why this worked. Why would /bin/kill
-9 work when the built in csh kill -9 wouldn't?
According to the manual page for the built-in kill command, it
recognizes 'kill -s 9', but not 'kill -9'.
What's even more awesome is that the csh manpage actually refers to
the use of the kill -[signal] syntax:
or from a command run at completion time:
complete kill 'p/*/`ps | awk \{print\ \$1\}`/'
kill -9 [^D]
23113 23377 23380 23406 23429 23529 23530 PID
Hooray for consistency.
I just checked the source and 'kill -9' should work, too. I believe
it was fixed on RELENG_7, i.e., tcsh 6.15a. RELENG_6 still has 6.14.
Jung-uk Kim
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: msdosfs performance unbearable
Alfred Perlstein wrote:
* Dominic Fandrey [EMAIL PROTECTED] [071127 00:47] wrote:
ufs:
$ time -h tar -xf php_manual_en.tar.gz
3.31s real 0.43s user 0.51s sys
msdosfs:
I stopped that after 45 minutes.
Also the system becomes barely responsive. The mouse moves extremely sloppy
and a key-press often causes 2 characters to be printed. Mouse-clicks are
either lost or take more than 10 seconds to be recognized.
Which version of FreeBSD? can you get more information about the
FAT system?
Csupped and build yesterday:
$ uname -a
FreeBSD mobileKamikaze.norad 7.0-BETA3 FreeBSD 7.0-BETA3 #0: Tue Nov 27
20:53:17 CET 2007
[EMAIL PROTECTED]:/usr/obj/TPR40-7/i386/usr/src/sys/TPR40-7 i386
Partition information:
/dev/ad0s3 on /mnt/msdos/software (msdosfs, local)
/dev/ad0s4 on /mnt/msdos/vault (msdosfs, local)
Actually I don't know any way of aquiring (= how is this spelled?) useful
data about Fat32 partitions in FreeBSD.
Anyway:
mobileKamikaze$ strace -o ~/msdos.trace tar -xf php_manual_en.tar.gz
^C
And here is the beginning of the trace:
execve(0xbfbfe608, [0xbfbfeaf4], [/* 0 vars */]) = 0
__sysctl([...], 0xbfbfe86c, 0xbfbfe870, NULL, 0) = 0
syscall_477(0, 0x110, 0x3, 0x1000, 0x, 0, 0) = 0x2808
munmap(0x2808, 272) = 0
__sysctl([...], 0x2807c87c, 0xbfbfe8d0, NULL, 0) = 0
syscall_477(0, 0x8000, 0x3, 0x1002, 0x, 0, 0) = 0x2808
issetugid(0x2807598c) = 0
open(/etc/libmap.conf, O_RDONLY) = 3
fstat(3, {st_mode=S_IFDIR|0543, st_size=18446253021508551011, ...}) = 0
read(3, , 4096) = 0
close(3)= 0
open(/var/run/ld-elf.so.hints, O_RDONLY) = 3
read(3, f/rtld.c:3297\n\0\0%s: Unexpected ..., 128) = 128
syscall_478(0x3, 0x80, 0, 0)= 0x80
read(3, /lib:/usr/lib:/usr/lib/compat:/u..., 274) = 274
close(3)= 0
access(/lib/libarchive.so.4, F_OK)= -1 ENOENT (No such file or directory)
access(/usr/lib/libarchive.so.4, F_OK) = 0
open(/usr/lib/libarchive.so.4, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pP\0\000..., 4096) =
4096
syscall_477(0, 0x25000, 0x5, 0x20002, 0x3, 0, 0) = 0x28088000
mprotect(0x280aa000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x280aa000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x280ab000, 0x1000, 0x3, 0x12, 0x3, 0x22000, 0) = 0x280ab000
syscall_477(0x280ac000, 0x1000, 0x3, 0x1012, 0x, 0, 0) = 0x280ac000
close(3)= 0
access(/lib/libbz2.so.3, F_OK)= -1 ENOENT (No such file or directory)
access(/usr/lib/libbz2.so.3, F_OK)= 0
open(/usr/lib/libbz2.so.3, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\21\0\000..., 4096)
= 4096
syscall_477(0, 0x11000, 0x5, 0x20002, 0x3, 0, 0) = 0x280ad000
mprotect(0x280bc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x280bc000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x280bd000, 0x1000, 0x3, 0x12, 0x3, 0xf000, 0) = 0x280bd000
close(3)= 0
access(/lib/libz.so.4, F_OK) = 0
open(/lib/libz.so.4, O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\27..., 4096) =
4096
syscall_477(0, 0x12000, 0x5, 0x20002, 0x3, 0, 0) = 0x280be000
mprotect(0x280ce000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x280ce000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x280cf000, 0x1000, 0x3, 0x12, 0x3, 0x11000, 0) = 0x280cf000
close(3)= 0
access(/lib/libc.so.7, F_OK) = 0
open(/lib/libc.so.7, O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\327\1..., 4096) =
4096
syscall_477(0, 0xfd000, 0x5, 0x20002, 0x3, 0, 0) = 0x280d
mprotect(0x281b2000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x281b2000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x281b3000, 0x6000, 0x3, 0x12, 0x3, 0xe2000, 0) = 0x281b3000
syscall_477(0x281b9000, 0x14000, 0x3, 0x1012, 0x, 0, 0) = 0x281b9000
close(3)= 0
syscall_477(0, 0x9000, 0x3, 0x1002, 0x, 0, 0) = 0x281cd000
sysarch(0xa, 0xbfbfe930)= 0
syscall_477(0, 0x4b0, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 1200)= 0
syscall_477(0, 0xa18, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 2584)= 0
syscall_477(0, 0x2b8, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 696) = 0
syscall_477(0, 0x408, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 1032)= 0
syscall_477(0, 0x51c8, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 20936) = 0
__sysctl([1025732.0], 2,
i7\350!\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
Re: Pthread scheduling in FreeBSD 7
On Tue, 27 Nov 2007, Gregor Maier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have a question concerning *pthread* scheduling with FreeBSD 7. Did this get answered already? I missed it if it did. My goal: I have a multi-threaded application, in which I have a thread that should get higher priority than the other threads. Realtime-Priority for this thread would be nice but is not necessary. My approach so far (which worked for FreeBSD 6.2): Use the libpthread implementation, use pthread_attr_setschedparam() to increase the priority (scope is PTHREAD_SCOPE_SYSTEM, policy is SCHED_RR). For the libpthread implemenation that worked fine and did just what I expected. I also tried it using libthr, but libthr didn't care about the priority. My prolbem in FreeBSD 7: The libpthread implementation seems to have gone and libthr is the default. However libthr still ignores the pthread scheduling parameters. (FreeBSD 7 has a different default priority and policy for libthr than FreeBSD 6 however). I also saw, that libkse is now available as a new M:N pthread implementation, so I tried using that. But libkse is significantly slower than libthr and libkse does not always schedule to all CPUs. As far as I can tell libkse only schedules to all CPUs if the load is small when the threads are created. I have never seen this behaviour with libpthread from FreeBSD 6. And libkse is quite unpredictable: I used a test program with 10 threads (with equal priority) and recorded the wall-runtime of each of them. The runtime of them differs by a factor of up to 5(!). I have to mention however, that I used different machines. The one running FreeBSD 6 is a dual-cpu AMD Athlon with 32bit OS, while the one running FreeBSD 7 is a dual-core Intel running a 64bit OS. In FreeBSD 6 I used SCHED_4BSD in the kernel, while I used SCHED_ULE in FreeBSD 7. My questions: * Can anyone shed some light on this issue? * How can I tune thread scheduling in FreeBSD 7? What happened to the libpthread implementation from FreeBSD 6? It is the same as libkse, just renamed. Other than setting the sysctl kern.threads.virtual_cpu (which defaults to the number of CPUs), there isn't much else. And if all threads are system scope, virtual_cpu 1 isn't of any use. * What triggers the whether libkse schedules to only one or to all CPUs? Is this tuneable? In both cases (system and process-scope threads) it is dependent on the kernel. For process scope threads, there is only one userland run-queue and threads are scheduled onto KSEs as they become available. When threads block in the kernel, an upcall is made and libkse runs another thread in that KSE. When threads unblock, the kernel puts them in the next KSE upcall - they are not bound to any specific upcall. What should be done is that threads should get bound to a specific upcall and they should stay there (N run queues to match N KSEs) and threads should only migrate to average the KSE loading. For system scope threads it is totally dependent on the kernel scheduler. * Do rtprio() and/or nice() work for single threads? I'm not sure about nice(), but rtprio only works if you have superuser privileges. * Any other ideas how I can assign a higher priority to a thread. Maybe even realtime priority? For libthr, priorities are only really used if the process has superuser privileges. Try running (if it is safe) it as root. You should set the scheduling class to SCHED_FIFO or SCHED_RR (see sched_setscheduler(2)). -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
USB memory stick as dump device
Hi, is it possible to use USB memory stick as dump device for panic dumps? I have a 6.2 box with gmirrors and no non-gmirror disks. I have never managed to get dumps work onto the swap partition on the mirror. So...is it possible to use USB stick as a dump device or should I not even try that? -- VH signature.asc Description: OpenPGP digital signature
Re: msdosfs performance unbearable
On Tue, 27 Nov 2007 09:47:24 +0100
Dominic Fandrey [EMAIL PROTECTED] wrote:
ufs:
$ time -h tar -xf php_manual_en.tar.gz
3.31s real 0.43s user 0.51s sys
I've seem something similar , in the past, on 6.2, when writing to my mobile
phone's mini-SD card.
what does gstat show? (in particular, is any device being used 100% ?, can u
relate the slowness when it hits 100% ? do other disks other than your FAT disk
become saturated too? )
cheers,
B
_
{Beto|Norberto|Numard} Meijome
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re(4) lockups on a MSI K9AG Neo2-Digital (7.0-BETA3 amd64)
Your patch makes this network card interesting. It is now working faster and saving more resources :-) I hope it will find it's way at least into -CURRENT The locukups might have been solved by your patch or by: http://lists.freebsd.org/pipermail/cvs-src/2007-November/084247.html Anyway, I have now 2 days uptime without any network-card or storage problems at all. Pyun YongHyeon schrieb: On Mon, Nov 26, 2007 at 09:10:43AM +0100, Martin Matuska wrote: Hi, I am using a MSI K9AG Neo2-Digital (MS-7368) mainboard with 7.0-BETA3 in amd64 mode at a german dedicated server provider. The mainboard has a onboard re(4) ethernet controller. I experience a very strange behaiviour: When there are large transfers on the onboard SATA controller the re(4) controller starts to have packet loss. This packet loss does not stop when there is no more load on ata(4). With another high load (like doing a full-system backup) the packet loss keeps increasing up to 90% and more - the system is not accesible over the internet anymore, packets get lost, SSH sessions or http requests get stale, I have to restart the system. I experience no kernel panics. Another (maybe related) problem that occurs (but does not effect system responsiveness) is described in: http://lists.freebsd.org/pipermail/freebsd-current/2007-November/080525.html Here is some information about the system: dmesg (boot -v): http://test.vx.sk/MS-7368/dmesg.txt pciconf -lcv: http://test.vx.sk/MS-7368/pciconf.txt dmidecode: http://test.vx.sk/MS-7368/dmidecode.txt I don't understand why this happens and would like to help debugging Me either. I have a WIP version that fixes other issues on re(4) but I'm not sure whether it mitigates your issue. The overhauled re(4) supports larger descriptors(256 instead of 64) and TSO. http://people.freebsd.org/~yongari/re/if_re.c http://people.freebsd.org/~yongari/re/if_rlreg.h this issue. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re(4) lockups on a MSI K9AG Neo2-Digital (7.0-BETA3 amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Matuska wrote: Your patch makes this network card interesting. It is now working faster and saving more resources :-) I hope it will find it's way at least into -CURRENT The locukups might have been solved by your patch or by: http://lists.freebsd.org/pipermail/cvs-src/2007-November/084247.html Anyway, I have now 2 days uptime without any network-card or storage problems at all. Roughly the same results here except the uptime because I did a few buildworlds for other reasons but I am getting about 80% of the rated speed for my ISP now (once headers are factored in it is almost 100%) - -- Aryeh M. Friedman Developer, not business, friendly http://www.flosoft-systems.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTXrRJ9+1V27SttsRAgunAKCJrseUsrB+TuP7vF4EF7EbUZ+pvgCeKzjM HxZizD+Cmerx4KM4EKk06JM= =KExM -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.2-RELEASE always hang
Hi all I'm using FreeBSD 6.2-RELEASE on Intel P4 3.0GHz, 512MB Ram computer. Its very irritatingly hangs very frequently, more than 10 times a day. Do others find FreeBSD 6.2-RELEASE always hangs? I simply cannot use it for any serious use, not even to send a mail, other than browsing web. I find it mostly when I try to move the mouse it hangs. Upward and downward cursor keys press and hold also hangs, but not always. These may be just coincidental. How do I find why it hangs? How is the stability of the upcoming 7.0? Best Regards Unga Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installation problems of FreeBSD 7 beta 2 on Dell D610 (multiboot con solaris, linux, winxp)
Julian H. Stacey wrote: Stefano stable@ I saw similar installing 7.0-BETA3 on my Digital HiHote Ultra .. I'll look for right syntax. eg maybe hw.ata.ata_dma=0 etc starting in my http://www.berklix.com/~jhs/hardware/laptops/#loader.conf Safe mode (Hit Key 3 after it asks for boot floppy 2nd time (Im using floppy as my cd drive doesnt like my cd-rw media, just cd-r) This sets hw.ata.ata_dma to 0, with this my laptop is now in middle of a minimal install, reading distrib via a pcmcia ep0 ethernet. Although that enables disk writes, Pcmcia ep0 runs slow, 23KB/s, timing out install has died repeatedly. I tried reducing commands used in bootsafekey of /sys/boot/forth/beastie.4th: http://www.berklix.com/~jhs/hardware/laptops/#bootsafekey By avoiding `3' just using set hw.ata.ata_dma boot Still its a slow 23K. Still ep0 dies. Install fails. -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com Ihr Rauch = mein allergischer Kopfschmerz. Dump cigs 4 snuff. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cryptodev and ssh on RELENG_7
On Tue, 27 Nov 2007 07:37:49 -0500 Mike Tancsa [EMAIL PROTECTED] wrote: I have a HiFN crypto card and can remember that it was used for ssh connections with 3des encryption (on 6.1 afair). But with RELENG_7 it isn't used at all (no interrupts) if I 'ssh -v -c 3des-cbc [EMAIL PROTECTED]' Any ideas what is wrong? dmesg: hifn0 mem 0x8000-0x8fff,0x8004-0x80041fff,0x8008-0x80087fff irq 12 at device 13.0 on pci0 hifn0: [ITHREAD] hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801ext clk, 4x mult crw-rw-rw- 1 root wheel - 0, 41 Nov 27 08:13:41 2007 /dev/crypto Hi, Are you sure you have device crypto and device cryptodev in the kernel? Also, there is a program in /usr/src/tools/tools/crypto called hifnstats. It will show some usuage stats. e.g. This issue is one of a gcc42 issue. But gcc42 is not wrong. OpenSSL has a using __FreeBSD_version issue. So to fix this issue, you should apply following patch. --- crypto/openssl/crypto/engine/eng_cryptodev.c.orig 2006-07-30 04:10:18.0 +0900 +++ crypto/openssl/crypto/engine/eng_cryptodev.c2007-11-08 01:55:35.0 +0900 @@ -32,7 +32,7 @@ #include openssl/bn.h #if (defined(__unix__) || defined(unix)) !defined(USG) \ - (defined(OpenBSD) || defined(__FreeBSD_version)) + (defined(OpenBSD) || defined(__FreeBSD__)) #include sys/param.h # if (OpenBSD = 200112) || ((__FreeBSD_version = 470101 __FreeBSD_version 50) || __FreeBSD_version = 500041) # define HAVE_CRYPTODEV ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2-RELEASE always hang
Unga wrote: Hi all I'm using FreeBSD 6.2-RELEASE on Intel P4 3.0GHz, 512MB Ram computer. Its very irritatingly hangs very frequently, more than 10 times a day. Do others find FreeBSD 6.2-RELEASE always hangs? I simply cannot use it for any serious use, not even to send a mail, other than browsing web. I find it mostly when I try to move the mouse it hangs. Upward and downward cursor keys press and hold also hangs, but not always. These may be just coincidental. How do I find why it hangs? How is the stability of the upcoming 7.0? Best Regards Unga I'm sure I'm not alone in this, but I'm running several 6.2-RELEASE-p8 boxes (servers and laptop workstations) for several months now without a single lock-up. I'd first look into hardware, testing memory, testing the power supply, and checking CPU/chipset temperatures as they have often contributed to problems similar to what you are describing. 6.2 has been working extremely well for me with no stability issues that weren't related to hardware problems. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2-RELEASE always hang
Hi, Unga wrote: Hi all I'm using FreeBSD 6.2-RELEASE on Intel P4 3.0GHz, 512MB Ram computer. Its very irritatingly hangs very frequently, more than 10 times a day. Do others find FreeBSD 6.2-RELEASE always hangs? I simply cannot use it for any serious use, not even to send a mail, other than browsing web. I find it mostly when I try to move the mouse it hangs. Upward and downward cursor keys press and hold also hangs, but not always. These may be just coincidental. How do I find why it hangs? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html should help you how to start finding out why :) How is the stability of the upcoming 7.0? You should try it on your hardware and see how it will perform. it can be more stable .. or less :) but it have to be faster :) Best Regards Unga Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.2-RELEASE always hang
On Nov 28, 2007 5:15 PM, Unga [EMAIL PROTECTED] wrote: 10 times a day. Do others find FreeBSD 6.2-RELEASE always hangs? no coincidental. How do I find why it hangs? hardware problem, i suppose. broken cpu fan? -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[releng_6 tinderbox] failure on sparc64/sparc64
TB --- 2007-11-28 16:44:30 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2007-11-28 16:44:30 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2007-11-28 16:44:30 - cleaning the object tree TB --- 2007-11-28 16:44:51 - cvsupping the source tree TB --- 2007-11-28 16:44:51 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/sparc64/sparc64/supfile TB --- 2007-11-28 16:44:57 - building world (CFLAGS=-O2 -pipe) TB --- 2007-11-28 16:44:57 - cd /src TB --- 2007-11-28 16:44:57 - /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything TB --- 2007-11-28 17:37:30 - generating LINT kernel config TB --- 2007-11-28 17:37:30 - cd /src/sys/sparc64/conf TB --- 2007-11-28 17:37:30 - /usr/bin/make -B LINT TB --- 2007-11-28 17:37:30 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2007-11-28 17:37:30 - cd /src TB --- 2007-11-28 17:37:30 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Nov 28 17:37:30 UTC 2007 stage 1: configuring the kernel -- cd /src/sys/sparc64/conf; PATH=/obj/sparc64/src/tmp/legacy/usr/sbin:/obj/sparc64/src/tmp/legacy/usr/bin:/obj/sparc64/src/tmp/legacy/usr/games:/obj/sparc64/src/tmp/usr/sbin:/obj/sparc64/src/tmp/usr/bin:/obj/sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /obj/sparc64/src/sys/LINT /src/sys/sparc64/conf/LINT config: /src/sys/sparc64/conf/LINT:687: only one machine directive is allowed *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2007-11-28 17:37:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2007-11-28 17:37:30 - ERROR: failed to build lint kernel TB --- 2007-11-28 17:37:30 - tinderbox aborted TB --- 2552.58 user 307.05 system 3179.86 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-sparc64-sparc64.full ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
Jan Srzednicki wrote: Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection so, what does netstat -aAn show? initiations/second. The socket is non-blocking. It does standard job of creating the socket, setting up the relevant fields, setting SO_REUSEADDR and SO_KEEPALIVE, setting O_NONBLOCK on the descriptor. No bind(2) is performed. The connection is initiated from inside a jail (not sure if that implies a internal bind(2) to the jail's address). There are no connections from the other host to the first one. I've tried tuning the net.inet.ip.portrange variables: I've increased the available portrange to over 45000 ports (quite a lot, should be more than enough for just anything) and I've toggled net.inet.ip.portrange.randomized off, but that didn't change anything. The workaround on the application side - retrying on EADDRINUSE - works pretty well, but hey, from what I know from the Stevens book, that shouldn't be happening, though Google said all BSD had a bad habit of throwing out EADDRINUSE from time to time. This all happens on a 6.2-RELEASE system. The symptoms are easily reproducable in my environment. Is there any known fix for that? If there ain't, can it be fixed? :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
Jan Srzednicki wrote: Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection initiations/second. This looks like the old (and probably well known) problem ab has. (ab is apache benchmark, a utility which is bundled with apache and which does repeated connections to the specified address, does transactions and computes some statistics). AFAIK this behaviour was present since at least 5.2, maybe earlier. No known fixes. signature.asc Description: OpenPGP digital signature
Re: connect() returns EADDRINUSE during massive host-host conn rate
On Tue, Nov 27, 2007 at 02:53:20PM +0100, Jan Srzednicki wrote: Hello, setting up the relevant fields, setting SO_REUSEADDR and SO_KEEPALIVE, setting O_NONBLOCK on the descriptor. No bind(2) is performed. The connection is initiated from inside a jail (not sure if that implies a internal bind(2) to the jail's address). There are no connections from the other host to the first one. And some additional info: subsequent connect()s on the same keep returning EADDRINUSE as well. In order to establish a connection, the application must create a brand new socket and then retry connect(). -- Jan Srzednicki :: http://wrzask.pl/ Remember, remember, the fifth of November -- V for Vendetta ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: Jan Srzednicki wrote: Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection so, what does netstat -aAn show? How can I get any usable information from netstat? It shows a bunch of connections, of course, but since connect(2) failed, I have no idea what local port I was trying to use. And, what I forgot to mention, it's a SMP box, which could matter in case of some race condition. -- Jan Srzednicki :: http://wrzask.pl/ Remember, remember, the fifth of November -- V for Vendetta ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
Jan Srzednicki wrote: On Wed, Nov 28, 2007 at 10:22:08AM -0800, Julian Elischer wrote: Jan Srzednicki wrote: Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection so, what does netstat -aAn show? How can I get any usable information from netstat? It shows a bunch of connections, of course, but since connect(2) failed, I have no idea what local port I was trying to use. but you can get an idea of the local socket distribution, and what state all the sockets are in (TIME_WAIT etc). And, what I forgot to mention, it's a SMP box, which could matter in case of some race condition. hopefully not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB memory stick as dump device
* V??clav Haisman [EMAIL PROTECTED] [071128 01:11] wrote: Hi, is it possible to use USB memory stick as dump device for panic dumps? I have a 6.2 box with gmirrors and no non-gmirror disks. I have never managed to get dumps work onto the swap partition on the mirror. So...is it possible to use USB stick as a dump device or should I not even try that? -- VH I don't think that will work currently. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cryptodev and ssh on RELENG_7
On 2007.11.29 01:51:44 +0900, Norikatsu Shigemura wrote: On Tue, 27 Nov 2007 07:37:49 -0500 Mike Tancsa [EMAIL PROTECTED] wrote: I have a HiFN crypto card and can remember that it was used for ssh connections with 3des encryption (on 6.1 afair). But with RELENG_7 it isn't used at all (no interrupts) if I 'ssh -v -c 3des-cbc [EMAIL PROTECTED]' Any ideas what is wrong? dmesg: hifn0 mem 0x8000-0x8fff,0x8004-0x80041fff,0x8008-0x80087fff irq 12 at device 13.0 on pci0 hifn0: [ITHREAD] hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801ext clk, 4x mult crw-rw-rw- 1 root wheel - 0, 41 Nov 27 08:13:41 2007 /dev/crypto Hi, Are you sure you have device crypto and device cryptodev in the kernel? Also, there is a program in /usr/src/tools/tools/crypto called hifnstats. It will show some usuage stats. e.g. This issue is one of a gcc42 issue. But gcc42 is not wrong. OpenSSL has a using __FreeBSD_version issue. So to fix this issue, you should apply following patch. Actually I just don't see how the code in question could have ever detected FreeBSD correctly, unless the normal OpenSSL build system does some magic for this (which it doesn't seem to). I'm doing make universe test builds with the patch below now. I will try test this with actual hardware tomorrow (if I can find it), but it's quite possible I won't have time until Friday to get something set up to test. If somebody else can test the patch below with some crypto hardware that would be great. Thanks for the patch btw. :-). --- crypto/openssl/crypto/engine/eng_cryptodev.c.orig 2006-07-30 04:10:18.0 +0900 +++ crypto/openssl/crypto/engine/eng_cryptodev.c 2007-11-08 01:55:35.0 +0900 @@ -32,7 +32,7 @@ #include openssl/bn.h #if (defined(__unix__) || defined(unix)) !defined(USG) \ - (defined(OpenBSD) || defined(__FreeBSD_version)) + (defined(OpenBSD) || defined(__FreeBSD__)) #include sys/param.h # if (OpenBSD = 200112) || ((__FreeBSD_version = 470101 __FreeBSD_version 50) || __FreeBSD_version = 500041) # define HAVE_CRYPTODEV -- Simon L. Nielsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature- rcvar woes
On Wednesday 28 November 2007 02:16:51 pm Andrei Kolu wrote: Something is wrong with rcvar or I am just blatant. For example: 1) Enable powerd in rc.conf # echo 'enable_powerd=YES' /etc/rc.conf 2) Launch powerd # /etc/rc.d/powerd start Starting powerd. 3) And stopping it. # /etc/rc.d/powerd stop Stopping powerd. Everything looks fine, but when I disable powerd in rc.conf then problem arise. 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. What? Not even a warning message and powerd is actually running- why I have to reboot to disable it? I know that I can stop it by enabling it in rc.conf but what the point? Same problem when I want to start some service without appropriate line in rc.conf. I'd prefer to see somekind of warning about misconfigured rc.conf or at least information about what's going on in reality. Use forcestart or forcestop to manage services that are not enabled in rc.conf. This is normal. If you got a warning, then on shutdown every rc.d script that is disabled would whine. Simiarly on boot since all rc.d scripts are started on boot. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
On Wed, 28 Nov 2007, Ivan Voras wrote: Jan Srzednicki wrote: Hello, I have a pair of hosts. One of them performs a massive amount of TCP connections to the other one, all to the same port. This setup mostly works fine, but from time to time (that varies, from once a minute to one a half an hour), the connect(2) syscall fails with EADDRINUSE. The connection rate tops to 50 connection initiations/second. This looks like the old (and probably well known) problem ab has. (ab is apache benchmark, a utility which is bundled with apache and which does repeated connections to the specified address, does transactions and computes some statistics). AFAIK this behaviour was present since at least 5.2, maybe earlier. No known fixes. Could it have anything to do with the listen backlog on the server end? -- DE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
questionable feature- rcvar woes
Something is wrong with rcvar or I am just blatant. For example: 1) Enable powerd in rc.conf # echo 'enable_powerd=YES' /etc/rc.conf 2) Launch powerd # /etc/rc.d/powerd start Starting powerd. 3) And stopping it. # /etc/rc.d/powerd stop Stopping powerd. Everything looks fine, but when I disable powerd in rc.conf then problem arise. 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. What? Not even a warning message and powerd is actually running- why I have to reboot to disable it? I know that I can stop it by enabling it in rc.conf but what the point? Same problem when I want to start some service without appropriate line in rc.conf. I'd prefer to see somekind of warning about misconfigured rc.conf or at least information about what's going on in reality. Andrei ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: msdosfs performance unbearable
* Dominic Fandrey [EMAIL PROTECTED] [071128 01:04] wrote:
Alfred Perlstein wrote:
* Dominic Fandrey [EMAIL PROTECTED] [071127 00:47] wrote:
ufs:
$ time -h tar -xf php_manual_en.tar.gz
3.31s real 0.43s user 0.51s sys
msdosfs:
I stopped that after 45 minutes.
Also the system becomes barely responsive. The mouse moves extremely sloppy
and a key-press often causes 2 characters to be printed. Mouse-clicks are
either lost or take more than 10 seconds to be recognized.
Which version of FreeBSD? can you get more information about the
FAT system?
Csupped and build yesterday:
$ uname -a
FreeBSD mobileKamikaze.norad 7.0-BETA3 FreeBSD 7.0-BETA3 #0: Tue Nov 27
20:53:17 CET 2007
[EMAIL PROTECTED]:/usr/obj/TPR40-7/i386/usr/src/sys/TPR40-7 i386
Partition information:
/dev/ad0s3 on /mnt/msdos/software (msdosfs, local)
/dev/ad0s4 on /mnt/msdos/vault (msdosfs, local)
Actually I don't know any way of aquiring (= how is this spelled?) useful
data about Fat32 partitions in FreeBSD.
Ok that's fine, I was wondering is the MSDOS filesystem over USB
or something? Is the UFS and MSDOSFS on the same media?
-Alfred
Anyway:
mobileKamikaze$ strace -o ~/msdos.trace tar -xf php_manual_en.tar.gz
^C
And here is the beginning of the trace:
execve(0xbfbfe608, [0xbfbfeaf4], [/* 0 vars */]) = 0
__sysctl([...], 0xbfbfe86c, 0xbfbfe870, NULL, 0) = 0
syscall_477(0, 0x110, 0x3, 0x1000, 0x, 0, 0) = 0x2808
munmap(0x2808, 272) = 0
__sysctl([...], 0x2807c87c, 0xbfbfe8d0, NULL, 0) = 0
syscall_477(0, 0x8000, 0x3, 0x1002, 0x, 0, 0) = 0x2808
issetugid(0x2807598c) = 0
open(/etc/libmap.conf, O_RDONLY) = 3
fstat(3, {st_mode=S_IFDIR|0543, st_size=18446253021508551011, ...}) = 0
read(3, , 4096) = 0
close(3)= 0
open(/var/run/ld-elf.so.hints, O_RDONLY) = 3
read(3, f/rtld.c:3297\n\0\0%s: Unexpected ..., 128) = 128
syscall_478(0x3, 0x80, 0, 0)= 0x80
read(3, /lib:/usr/lib:/usr/lib/compat:/u..., 274) = 274
close(3)= 0
access(/lib/libarchive.so.4, F_OK)= -1 ENOENT (No such file or
directory)
access(/usr/lib/libarchive.so.4, F_OK) = 0
open(/usr/lib/libarchive.so.4, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pP\0\000..., 4096) =
4096
syscall_477(0, 0x25000, 0x5, 0x20002, 0x3, 0, 0) = 0x28088000
mprotect(0x280aa000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x280aa000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x280ab000, 0x1000, 0x3, 0x12, 0x3, 0x22000, 0) = 0x280ab000
syscall_477(0x280ac000, 0x1000, 0x3, 0x1012, 0x, 0, 0) = 0x280ac000
close(3)= 0
access(/lib/libbz2.so.3, F_OK)= -1 ENOENT (No such file or
directory)
access(/usr/lib/libbz2.so.3, F_OK)= 0
open(/usr/lib/libbz2.so.3, O_RDONLY) = 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\21\0\000..., 4096)
= 4096
syscall_477(0, 0x11000, 0x5, 0x20002, 0x3, 0, 0) = 0x280ad000
mprotect(0x280bc000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x280bc000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x280bd000, 0x1000, 0x3, 0x12, 0x3, 0xf000, 0) = 0x280bd000
close(3)= 0
access(/lib/libz.so.4, F_OK) = 0
open(/lib/libz.so.4, O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\27..., 4096) =
4096
syscall_477(0, 0x12000, 0x5, 0x20002, 0x3, 0, 0) = 0x280be000
mprotect(0x280ce000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x280ce000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x280cf000, 0x1000, 0x3, 0x12, 0x3, 0x11000, 0) = 0x280cf000
close(3)= 0
access(/lib/libc.so.7, F_OK) = 0
open(/lib/libc.so.7, O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, \177ELF\1\1\1\t\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\327\1..., 4096) =
4096
syscall_477(0, 0xfd000, 0x5, 0x20002, 0x3, 0, 0) = 0x280d
mprotect(0x281b2000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x281b2000, 4096, PROT_READ|PROT_EXEC) = 0
syscall_477(0x281b3000, 0x6000, 0x3, 0x12, 0x3, 0xe2000, 0) = 0x281b3000
syscall_477(0x281b9000, 0x14000, 0x3, 0x1012, 0x, 0, 0) = 0x281b9000
close(3)= 0
syscall_477(0, 0x9000, 0x3, 0x1002, 0x, 0, 0) = 0x281cd000
sysarch(0xa, 0xbfbfe930)= 0
syscall_477(0, 0x4b0, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 1200)= 0
syscall_477(0, 0xa18, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 2584)= 0
syscall_477(0, 0x2b8, 0x3, 0x1000, 0x, 0, 0) = 0x281d6000
munmap(0x281d6000, 696) = 0
Re: missing .cshrc and pf.conf after upgrade to 7.0-beta3
Miroslav Lachman wrote: I am not 100% sure, maybe I overlook something in binary major version upgrade procedure, but after upgrade from 6.2 to 7.0-BETA3 my roots ~/.cshrc was accidentally replaced with dist version of .cshrc and /etc/pf.conf is missing. The fact that /etc/pf.conf disappeared is due to it being removed from the release (it is now in /usr/share/examples/etc). The fact that /.cshrc was upgraded in spite of having been locally modified is probably a bad idea -- I'll change the default freebsd-update.conf to deal with this. Colin Percival ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature- rcvar woes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 28 Nov 2007 20:37+0100, Milan Obuch wrote: On Wednesday 28 November 2007 20:16:51 Andrei Kolu wrote: 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. Stop for a moment - enable_powerd means actually 'enable action carried by /etc/rc.d/powerd script', using this semantics actually explains all details. Or you could treat it as a stack of a sort, reversing order to 2) 1) just produces desired output. /etc/rc.d/powerd forcestop will execute the stop code regardless of the rcvar in /etc/rc.conf or similar files. rc.subr(8) is your friend, or perhaps not. - -- - -- Trond Endrestøl | [EMAIL PROTECTED] Patron of The Art of Computer Programming| FreeBSD 6.2-S Pine 4.64 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHTcfEbYWZalUoElsRArYeAJ43hVs5zf6TkMHr3oVMeiZLiAPfHwCfW1rX AGUV8Ae6RpDx0g8Jq3mv9oU= =XJkD -END PGP SIGNATURE-___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature- rcvar woes
On Wednesday 28 November 2007 20:16:51 Andrei Kolu wrote: Something is wrong with rcvar or I am just blatant. For example: 1) Enable powerd in rc.conf # echo 'enable_powerd=YES' /etc/rc.conf 2) Launch powerd # /etc/rc.d/powerd start Starting powerd. 3) And stopping it. # /etc/rc.d/powerd stop Stopping powerd. Agree - everything just fine. Everything looks fine, but when I disable powerd in rc.conf then problem arise. 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. Stop for a moment - enable_powerd means actually 'enable action carried by /etc/rc.d/powerd script', using this semantics actually explains all details. Or you could treat it as a stack of a sort, reversing order to 2) 1) just produces desired output. What? Not even a warning message and powerd is actually running- why I have to reboot to disable it? I know that I can stop it by enabling it in rc.conf but what the point? Same problem when I want to start some service without appropriate line in rc.conf. I'd prefer to see somekind of warning about misconfigured rc.conf or at least information about what's going on in reality. I hope my explanation above suffices. I was hit by this too, but rc.d scripts behavior is well designed and understandable. If, for some reason, you are still hit with described behavior, there is a save rope - /etc/rc.d/powerd forcestop will stop powerd even if there is no enable var in rc.conf. Regards, Milan -- No need to mail me directly. Just reply to mailing list, please. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature- rcvar woes
In the last episode (Nov 28), Andrei Kolu said: Something is wrong with rcvar or I am just blatant. For example: 1) Enable powerd in rc.conf # echo 'enable_powerd=YES' /etc/rc.conf 2) Launch powerd # /etc/rc.d/powerd start Starting powerd. 3) And stopping it. # /etc/rc.d/powerd stop Stopping powerd. Everything looks fine, but when I disable powerd in rc.conf then problem arise. 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. What? Not even a warning message and powerd is actually running- why I have to reboot to disable it? I know that I can stop it by enabling it in rc.conf but what the point? Same problem when I want to start some service without appropriate line in rc.conf. I'd prefer to see somekind of warning about misconfigured rc.conf or at least information about what's going on in reality. Try /etc/rc.d/powerd forcestop. What happens during startup and shutdown is that all rc.d scripts are run with start or stop arguments, and only the ones that have been enabled do anything. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature- rcvar woes
Wednesday 28 November 2007 21:55:44 kirjutas Trond Endrestøl: On Wed, 28 Nov 2007 20:37+0100, Milan Obuch wrote: On Wednesday 28 November 2007 20:16:51 Andrei Kolu wrote: 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. Stop for a moment - enable_powerd means actually 'enable action carried by /etc/rc.d/powerd script', using this semantics actually explains all details. Or you could treat it as a stack of a sort, reversing order to 2) 1) just produces desired output. /etc/rc.d/powerd forcestop will execute the stop code regardless of the rcvar in /etc/rc.conf or similar files. rc.subr(8) is your friend, or perhaps not. I know rcvar well enough and that force* feature too, what I don't like is that sometimes from command line you'll never know if it is a problem with wrong line in rc.conf or something else... Of course it is good if during boot there is no useless messages scrolling. So, rcvar can't detect if it was launched bye rc or from shell? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: connect() returns EADDRINUSE during massive host-host conn rate
Daniel Eischen wrote: On Wed, 28 Nov 2007, Ivan Voras wrote: This looks like the old (and probably well known) problem ab has. (ab is apache benchmark, a utility which is bundled with apache and which does repeated connections to the specified address, does transactions and computes some statistics). AFAIK this behaviour was present since at least 5.2, maybe earlier. No known fixes. Could it have anything to do with the listen backlog on the server end? No, since the same utility used from Linux (not the same binary...) works as it should. signature.asc Description: OpenPGP digital signature
Re: questionable feature- rcvar woes
On Wed, Nov 28, 2007 at 08:37:30PM +0100, Milan Obuch wrote: ... Agree - everything just fine. Everything looks fine, but when I disable powerd in rc.conf then problem arise. 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. Stop for a moment - enable_powerd means actually 'enable action carried by /etc/rc.d/powerd script', using this semantics actually explains all details. Or you could treat it as a stack of a sort, reversing order to 2) 1) just produces desired output. What? Not even a warning message and powerd is actually running- why I have to reboot to disable it? I know that I can stop it by enabling it in rc.conf but what the point? Same problem when I want to start some service without appropriate line in rc.conf. I'd prefer to see somekind of warning about misconfigured rc.conf or at least information about what's going on in reality. I hope my explanation above suffices. I was hit by this too, but rc.d scripts behavior is well designed and understandable. If, for some reason, you are still hit with described behavior, there is a save rope - /etc/rc.d/powerd forcestop will stop powerd even if there is no enable var in rc.conf. Agree, agree, agree. This is just something that any up-to-date admin should be aware of and in tune with. Yes, it's a bit different from how some-but-not-all start/stop scripts behaved in 4.x or older systems, but it's a very sensible behavior and it makes the /etc/rc.d and /usr/local/etc/rc.d scripts behave much more coherently and consistently. There are two different ways to get it to DWIM - either get in the habit of doing 2) then 1), or get in the habit of using forcestop. Given this, I don't see it as a problem. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questionable feature- rcvar woes
Here's where I must disagree -- and you just explained why -- ...admin should be aware of. Nonsense! I do not have time in my life to keep track of every nuance of every version of every OS. I fell into this same trap. Took me a while to figure it out. That's why I don't have time to take on other such trivialities! (It would be interesting to take a poll to determine how many wasted hours this silly gotcha has cost the members of this list, but let's not waste the bandwidth.) The script should be smart enough to know whether the it is being invoked through bootup/shutdown vs. admin interactive and should behave appropriately. If this was hard to do or unreliable, maybe it wouldn't be worthwhile doing, but it would be so easy to fix; at the crudest level just pass in an extra parm in the startup/shutdown sequence and act on that... Clifton Royston wrote: On Wed, Nov 28, 2007 at 08:37:30PM +0100, Milan Obuch wrote: ... Agree - everything just fine. Everything looks fine, but when I disable powerd in rc.conf then problem arise. 1) Disable powerd in rc.conf- comment it out. # enable_powerd=YES 2) Stop powerd # /etc/rc.d/powerd stop ...silence- nothing in logs either. Stop for a moment - enable_powerd means actually 'enable action carried by /etc/rc.d/powerd script', using this semantics actually explains all details. Or you could treat it as a stack of a sort, reversing order to 2) 1) just produces desired output. What? Not even a warning message and powerd is actually running- why I have to reboot to disable it? I know that I can stop it by enabling it in rc.conf but what the point? Same problem when I want to start some service without appropriate line in rc.conf. I'd prefer to see somekind of warning about misconfigured rc.conf or at least information about what's going on in reality. I hope my explanation above suffices. I was hit by this too, but rc.d scripts behavior is well designed and understandable. If, for some reason, you are still hit with described behavior, there is a save rope - /etc/rc.d/powerd forcestop will stop powerd even if there is no enable var in rc.conf. Agree, agree, agree. This is just something that any up-to-date admin should be aware of and in tune with. Yes, it's a bit different from how some-but-not-all start/stop scripts behaved in 4.x or older systems, but it's a very sensible behavior and it makes the /etc/rc.d and /usr/local/etc/rc.d scripts behave much more coherently and consistently. There are two different ways to get it to DWIM - either get in the habit of doing 2) then 1), or get in the habit of using forcestop. Given this, I don't see it as a problem. -- Clifton -- Mike Lempriere- Home: [EMAIL PROTECTED] Phone: 206-780-2146 Cellphone: 206-200-5902; text pager: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
