Re: Problem with find -prune...
Mike Meyer wrote: find -prune seems to not quite do what it says. At least, when delete is used. Here's an example tree (on 7.0-RELEASE, amd64 build): It behaves exactly as documented. I'll try to explain. bhuda% find /tmp/x -prune /tmp/x Hmm, it prints the root of the tree. That might be a bug; might not. It's not a bug: -prune prevents find(1) from descending *into* the directory, but the directory itself is still handled. bhuda% find /tmp/x -prune -o -print bhuda% Making the print conditional on not pruning, and we always prune. Ok, now let's look at what looks to me like a bug: bhuda% find /tmp/x -prune -o -delete find: /tmp/x/y: Permission denied Why on earth (or off it) is find trying to look at /tmp/x? Am I correct in assuming that this is a bug? The -delete primary implicitly assumes depth-first traversal (i.e. the -d option), because that's the only way you can delete a whole directory tree. However, when depth-first traversal is in effect, the -prune primary doesn't have any effect (for obvious reasons). It's documented in the manpage. In other words, the primaries -prune and -delete are mutual exclusive. It could be argued whether find(1) should print a warning in that case. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd IRIX is about as stable as a one-legged drunk with hypothermia in a four-hundred mile per hour wind, balancing on a banana peel on a greased cookie sheet -- when someone throws him an elephant with bad breath and a worse temper. -- Ralf Hildebrandt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with find -prune...
On Thu, 3 Apr 2008 17:59:20 +0200 (CEST) Oliver Fromme [EMAIL PROTECTED] wrote: Mike Meyer wrote: find -prune seems to not quite do what it says. At least, when delete is used. Here's an example tree (on 7.0-RELEASE, amd64 build): It behaves exactly as documented. I'll try to explain. I think you did an excellent job. Thank you. bhuda% find /tmp/x -prune -o -delete find: /tmp/x/y: Permission denied Why on earth (or off it) is find trying to look at /tmp/x? Am I correct in assuming that this is a bug? The -delete primary implicitly assumes depth-first traversal (i.e. the -d option), because that's the only way you can delete a whole directory tree. However, when depth-first traversal is in effect, the -prune primary doesn't have any effect (for obvious reasons). It's documented in the manpage. In other words, the primaries -prune and -delete are mutual exclusive. It could be argued whether find(1) should print a warning in that case. It might be better documented, also. So the bug that I'm *really* trying to scratch is in /etc/periodic/daily/100.clean-disks: rc=$(find / \( ! -fstype local -o -fstype rdonly \) -a -prune -o \ \( $args \) -atime +$daily_clean_disks_days -delete $print | tee /dev/stderr | wc -l) where it's using -prune and -delete in the same call to find. So I'll see if I can patch this, and file *that* bug report. Thanks again, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Is describing sysctl variables useful?
At work, I'm trying to get some measurements for what is going on on various systems, especially when developers are trying to use them. (The goal is to improve the situation; measurement is a rather early step in that process.) To that end, I've cobbled up a Perl script that acts as a wrapper around time(1) and uses that command to obtain the rusage (ref. getrusage(2)) information about the command in question. I've started to expand this to try to obtain information about the machine as a whole, in order to allow a comparison of the results from one run of a command to another to have some plausible meaning. For this, I thought that certain values reported by sysctl(8) might be of use. In the process of starting to investigate this, I noted that while some of the variables have decscriptions (ref. sysctl -d), others lack them. Since I'm likely to be sniffing around to figure out what these things are, would it be a useful exercise for me to submit PRs (in appropriately-sized chunks) to provide such descriptions? I have no desire to submit PRs merely for the exercise; I've submitted PRs before, so I'm unlikely to do it merely for the sake of novelty. :-} But if it stands a reasonable chance of being a useful thing for the project, I'm happy to help. Thoughts? Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp7LDgP5CbO3.pgp Description: PGP signature
Re: Is describing sysctl variables useful?
On Thu, Apr 3, 2008 at 11:26 PM, David Wolfskill [EMAIL PROTECTED] wrote: At work, I'm trying to get some measurements for what is going on on various systems, especially when developers are trying to use them. (The goal is to improve the situation; measurement is a rather early step in that process.) To that end, I've cobbled up a Perl script that acts as a wrapper around time(1) and uses that command to obtain the rusage (ref. getrusage(2)) information about the command in question. I've started to expand this to try to obtain information about the machine as a whole, in order to allow a comparison of the results from one run of a command to another to have some plausible meaning. For this, I thought that certain values reported by sysctl(8) might be of use. In the process of starting to investigate this, I noted that while some of the variables have decscriptions (ref. sysctl -d), others lack them. Since I'm likely to be sniffing around to figure out what these things are, would it be a useful exercise for me to submit PRs (in appropriately-sized chunks) to provide such descriptions? I have no desire to submit PRs merely for the exercise; I've submitted PRs before, so I'm unlikely to do it merely for the sake of novelty. :-} But if it stands a reasonable chance of being a useful thing for the project, I'm happy to help. Thoughts? Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Hi David, There is such project on the project ideas page : http://www.freebsd.org/projects/ideas/#p-docsysctl Maybe you can ping the listed technical contacts... Regards, Niki ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is describing sysctl variables useful?
The project that Niki is referring to is something I've begun working on as part of a independent project for school. Sysctl documentation strings are definitely wanted. Mat (@freeebsd) has a partially complete sysctl documentation branch in perforce (//depot/user/mat/src/sysctl_cleanup/). You might want to look there first in case the work has already been done but not integrated. Elijah On Thu, Apr 3, 2008 at 3:26 PM, David Wolfskill [EMAIL PROTECTED] wrote: At work, I'm trying to get some measurements for what is going on on various systems, especially when developers are trying to use them. (The goal is to improve the situation; measurement is a rather early step in that process.) To that end, I've cobbled up a Perl script that acts as a wrapper around time(1) and uses that command to obtain the rusage (ref. getrusage(2)) information about the command in question. I've started to expand this to try to obtain information about the machine as a whole, in order to allow a comparison of the results from one run of a command to another to have some plausible meaning. For this, I thought that certain values reported by sysctl(8) might be of use. In the process of starting to investigate this, I noted that while some of the variables have decscriptions (ref. sysctl -d), others lack them. Since I'm likely to be sniffing around to figure out what these things are, would it be a useful exercise for me to submit PRs (in appropriately-sized chunks) to provide such descriptions? I have no desire to submit PRs merely for the exercise; I've submitted PRs before, so I'm unlikely to do it merely for the sake of novelty. :-} But if it stands a reasonable chance of being a useful thing for the project, I'm happy to help. Thoughts? Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpghttp://www.catwhisker.org/%7Edavid/publickey.gpgfor my public key. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
7.0-RELEASE Kernel Panic in _mtx_lock_sleep() on shutdown
Hi all, I am getting panic()s upon each shutdown (visibly after disks have been synced). kgdb reveals the at /usr/src/sys/kern/kern_mutex.c:335 _mtx_lock_sleep() as the culprit. Running 7.0-RELEASE with root mounted from a ZFS file system. Seems to only have started since creating a second raidz data pool (mia-data), yet dismounting this before shutdown does not stop the panic(). uname: FreeBSD mia.dhcp.sjkwi.com.au 7.0-RELEASE FreeBSD 7.0-RELEASE #1: Sun Mar 2 07:26:17 EST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MIA amd64 zpool list: NAMESIZEUSED AVAILCAP HEALTH ALTROOT mia-data 2.03T 1.05T 1003G51% ONLINE - mia-sys 288G 9.58G278G 3% ONLINE - panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x258 fault code = supervisor read data, page not present instruction pointer = 0x8:0x802c805a stack pointer = 0x10:0xb33eb840 frame pointer = 0x10:0xff00011109c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1 (init) trap number = 12 panic: page fault cpuid = 0 kgdb output: #0 doadump () at pcpu.h:194 #1 0x0004 in ?? () #2 0x802d271f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #3 0x802d2b48 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:563 #4 0x804a510a in trap_fatal (frame=0xff00011109c0, eva=18446742974215805136) at /usr/src/sys/amd64/amd64/trap.c:724 #5 0x804a54b1 in trap_pfault (frame=0xb33eb790, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641 #6 0x804a5d6f in trap (frame=0xb33eb790) at /usr/src/sys/amd64/amd64/trap.c:410 #7 0x8048cbce in calltrap () at /usr/src/sys/amd64/amd64/exception.S:169 #8 0x802c805a in _mtx_lock_sleep (m=0xff00068772d8, tid=18446742974215817664, opts=Variable opts is not available. ) at /usr/src/sys/kern/kern_mutex.c:335 #9 0x803445b3 in vrele (vp=0xff00068771f0) at /usr/src/sys/kern/vfs_subr.c:2128 #10 0x80344b46 in vflush (mp=Variable mp is not available. ) at /usr/src/sys/kern/vfs_subr.c:2441 #11 0x8082e0ac in ?? () #12 0xff000636a000 in ?? () #13 0xff000636a054 in ?? () #14 0x5000 in ?? () #15 0x0008 in ?? () #16 0xb33eba60 in ?? () #17 0x in ?? () #18 0xff00011109c0 in ?? () #19 0x0008 in ?? () #20 0x5000 in ?? () #21 0x0008 in ?? () #22 0x in ?? () #23 0x8033d874 in dounmount (mp=0xff0006348ca0, flags=17893824, td=0x8) at /usr/src/sys/kern/vfs_mount.c:1286 #24 0x80343129 in vfs_unmountall () at /usr/src/sys/kern/vfs_subr.c:2936 #25 0x802d297f in boot (howto=8) at /usr/src/sys/kern/kern_shutdown.c:391 #26 0x802d2c9d in reboot (td=Variable td is not available. ) at /usr/src/sys/kern/kern_shutdown.c:169 #27 0x804a571c in syscall (frame=0xb33ebc70) at /usr/src/sys/amd64/amd64/trap.c:852 #28 0x8048cddb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:290 #29 0x0040854c in ?? () instruction pointer: #8 0x802c805a in _mtx_lock_sleep (m=0xff00068772d8, tid=18446742974215817664, opts=Variable opts is not available. ) at /usr/src/sys/kern/kern_mutex.c:335 dmesg (cut due to long length: http://users.sjkwi.com.au/sam/fbsd/dmesg.txt kernel config (cut due to long length): http://users.sjkwi.com.au/sam/fbsd/MIA Any ideas? -- Kind regards, Sam Kingston SJK Web Industries Email [EMAIL PROTECTED] Webhttp://www.sjkwi.com.au ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
force kernel dump - problems
Hi, I am trying to force kernel dump, and observing weird behavior: I have created kernel module that registers sysctl for me, after touching that sysctl it calls dumpsys() function which is supposed to dump kernel to disk. This is what i get in dmesg and on console --- Physical memory: 243 MB Dumping 35 MB:Attempt to write outside dump device boundaries. Offset: 14008330027167693824 mediaoffset: 3221225472 mediasize: 14008330023983906816 , length: 512 ** DUMP FAILED (ERROR 6) ** --- (The Offset.* line was added by me to the kernel source for debugging, but anyway it shows weird values - the same regardless of swap device i choose via dumpon ( i have 2 swap partitions for this) ). Can anyone help me with this ?, I would like to know first how to obtain kernel dump, then how to check why it doesn't work my way. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is describing sysctl variables useful?
About syscl(3) OID description lack, i send my Google Summer Code application to complete it this summer ;). I identify alls lacks in sysctl at http://6dev.net/~sbz/sysctl.txt and i want to correct them during Google Summer Code. My application was sent since 30 March 2008 via Google student Web application. Best Regards -- sbz On Thu, Apr 3, 2008 at 10:26 PM, David Wolfskill [EMAIL PROTECTED] wrote: At work, I'm trying to get some measurements for what is going on on various systems, especially when developers are trying to use them. (The goal is to improve the situation; measurement is a rather early step in that process.) To that end, I've cobbled up a Perl script that acts as a wrapper around time(1) and uses that command to obtain the rusage (ref. getrusage(2)) information about the command in question. I've started to expand this to try to obtain information about the machine as a whole, in order to allow a comparison of the results from one run of a command to another to have some plausible meaning. For this, I thought that certain values reported by sysctl(8) might be of use. In the process of starting to investigate this, I noted that while some of the variables have decscriptions (ref. sysctl -d), others lack them. Since I'm likely to be sniffing around to figure out what these things are, would it be a useful exercise for me to submit PRs (in appropriately-sized chunks) to provide such descriptions? I have no desire to submit PRs merely for the exercise; I've submitted PRs before, so I'm unlikely to do it merely for the sake of novelty. :-} But if it stands a reasonable chance of being a useful thing for the project, I'm happy to help. Thoughts? Peace, david -- David H. Wolfskill [EMAIL PROTECTED] I submit that conspiracy would be an appropriate collective noun for cats. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -- sbz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
