Re: Coming back to the btxld: No such file or directory installworld error
On Sun, Jun 27, 2010 at 10:54 PM, Ruslan Ermilov r...@freebsd.org wrote: On Sun, Jun 27, 2010 at 01:14:59PM -0700, Garrett Cooper wrote: Hi Ruslan, I've run into this particular error twice now in the past couple of weeks when building with -j24 on a memory disk and I was wondering if there was an missing dependency / race somewhere or something (perhaps make obj?): === sys/boot/i386/boot2 (install) # ... btxld -v -E 0x2000 -f bin -b /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: No such file or directory *** Error code 1 The install target isn't supposed to build stuff, only install it. When you see it trying to build something, this can be indicative of: - build wasn't run (e.g., after an update); Not the case (I ran buildworld and everything else up to that point installed happily). - a computer's date/time is set to the past (causing wrong date/time to be set on output files = causing them to be considered out-of- date by make(1)); check with date(1). My computer hasn't been time traveling lately :/ (If my calculations are correct, when this baby hits eighty-eight miles per hour... you're gonna see some serious shit.). - source files have modification times pointing to the future which fools make(1) into thinking that it should rebuild some target; check with find /usr/src -mtime -0. This seems unlikely as well. Is there a possibility that the existing Makefiles work by accident when -j 24 because the actions aren't executed in order :(? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
M. Warner Losh i...@bsdimp.com writes: Why not fix pidfile_open to not return a file handle when the PID doesn't match? It doesn't. If it can't lock the file, or if fstat(2) fails after it has locked the file, it returns NULL. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
M. Warner Losh i...@bsdimp.com writes: Maybe the real problem is that devd locks the file, then dies. The file remains locked, so the flopen is failing with EWOULDBLOCK. The lock is released when the process that holds it terminates. But I suspect the real real problem is the implicit assumption that flock will release the lock when a process terminates... That isn't the case in BSD Yes it is. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
Dag-Erling Smørgrav d...@des.no writes: M. Warner Losh i...@bsdimp.com writes: Maybe the real problem is that devd locks the file, then dies. The file remains locked, so the flopen is failing with EWOULDBLOCK. The lock is released when the process that holds it terminates. But I suspect the real real problem is the implicit assumption that flock will release the lock when a process terminates... That isn't the case in BSD Yes it is. Additional details: - Under POSIX semantics (fcntl(2) locks), the lock is released when *any* file descriptor the process holds for that file is closed. This is handled in fdfree(). - Under flock semantics (flock(2) locks), the lock is released when *all* file descriptors the process holds for that file is closed. This is handled in vn_closefile(). - In both cases, all locks a process holds are released when the process terminates. Gotta love the following excerpt from VOP_OPEN(9), btw: The VOP_OPEN() entry point is called before a file is accessed by a process and the VOP_CLOSE() entry point is called after a file is fin‐ ished with by the process. :) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Hi again, After my most recent appeal for testers, I received some excellent feedback and thank everyone that has tried the patch. I've ironed out a couple of bugs and have what I hope is the import-ready candidate patch available for a final round of testing. Please read on if you are able and willing to (re)test the code. On 06/19/10 13:27, Lawrence Stewart wrote: Amount of feedback received thus far: nichts, nil, nada *sings I'm so ronery in his best Kim Jong-il voice* [4] Just like Uncle Sam [5], Uncle Lawrence needs you too - yes, I'm pointing at YOU! More specifically, people out there running current with 10-15 mins to spare for some testing, please read on. On 06/13/10 18:12, Lawrence Stewart wrote: Hi all, The time has come to solicit some external testing for my SIFTR tool. I'm hoping to commit it within a week or so unless problems are discovered. SIFTR is a kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. You can use the data to find bugs in the stack, understand why connections are performing badly and test new code to name a few uses. Development has been made possible in part by grants from the Cisco University Research Program Fund at Community Foundation Silicon Valley, and the FreeBSD Foundation. Bringing it into FreeBSD proper is being carried out under the auspices of the Enhancing the FreeBSD TCP Implementation FreeBSD Foundation project. More details are available at [1,2,3]. If you can help out, please read on! [snip] Latest patch which fixes 2 bugs reported by testers and adds a bit more discussion to the man page is available here: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/siftr_9.x.r209558.patch Fixed bugs: - Running SIFTR on an INVARIANTS enabled kernel with a large number of TCP flows terminating on the machine would lead to a KASSERT triggering in the ALQ framework when SIFTR was disabled. - The SACK enabled data log message field was not being set correctly. If you would like to test on a kernel revision older then r209558, make sure you have my r209325 diff to sys/pcpu.h applied. It is safe to apply r209325 stand alone as it is self contained and not used by any code in the tree other than SIFTR. Please adapt the following instructions as appropriate based on the patch version you're testing. Copy it to the root of your source tree and run the following: patch -p1 siftr_9.x.r209119.patch It's a loadable kernel module so you can build it for testing like so: cd path/to/src/sys/modules/siftr make kldload ./siftr.ko (don't forget to make cleandir to remove cruft when finished testing) It turns out that the above instructions to build the module can produce a .ko that is out of sync with your kernel in such a way that the module can load, but may blow up unexpectedly. This was observed when KTR was enabled in the running kernel. To be safe, please use the following procedure instead: - Ensure path/to/src is the source tree that the kernel you are currently running was built from. cd path/to/src make buildkernel cp /usr/obj/path/to/src/sys/KERNCONF/modules/path/to/src/sys/modules/siftr/siftr.ko /tmp kldload /tmp/siftr.ko Alternatively for the last 2 steps, you can make installkernel ; shutdown -r now after the kernel build completes and then simply kldload siftr as the module will be installed to /boot/kernel/ as per usual. After applying the patch, you can read the man page by running: man -M path/to/src/share/man siftr If I've done a decent job, all the info you need to understand what it does and how to use it should be in the man page. I'm interested in all feedback and reports of success/failure, along with details of the architecture tested and number of CPUs if you would be so kind. That should be enough to get the ball rolling. Thanks and I look forward to hearing from you! Cheers, Lawrence [1] http://caia.swin.edu.au/freebsd/etcp09/ [2] http://www.freebsdfoundation.org/projects.shtml#Swinburne [3] http://caia.swin.edu.au/urp/newtcp/ [4] http://www.youtube.com/watch?v=xh_9QhRzJEs (language warning) [5] http://www.sonofthesouth.net/uncle-sam/images/uncle-sam-wants-you.jpg Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
Dag-Erling Smørgrav d...@des.no writes: - Under flock semantics (flock(2) locks), the lock is released when *all* file descriptors the process holds for that file is closed. are, even, and sorry for the horrid quoting. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] BSDL iconv in base system
Em 2010.06.17. 23:21, Anonymous escreveu: Gabor Kovesdanga...@freebsd.org writes: [...] $ make installworld TARGET=i386 DESTDIR=/b/bbb ... === usr.bin/mkcsmapper (install) install -s -o root -g wheel -m 555 mkcsmapper /b/bbb/usr/bin strip: /b/bbb/usr/bin/mkcsmapper: File format not recognized install: wait: No such file or directory *** Error code 70 If cross-compiling doesn't work, how did you build the former one that gave you that error? Here is my guess libiconv_modules compiles fine but installs both normal and lib32 objdir into /usr/lib when lib32 should use /usr/lib32. mkcsmapper/mkesdb are failing to install because they're treated as build-tools for host system and never compiled for target system. However, they're not included in lib32 target and so are not built for i386 arch during normal buildworld on amd64 host where host = target. Just a short update on this... The library part is fixed but I couldn't find out a fix for mk* tools yet. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Coming back to the btxld: No such file or directory installworld
On Sun, 2010-06-27 at 13:14 -0700, Garrett Cooper wrote: Hi Ruslan, I've run into this particular error twice now in the past couple of weeks when building with -j24 on a memory disk and I was wondering if there was an missing dependency / race somewhere or something (perhaps make obj?): === sys/boot/i386/boot2 (install) # ... btxld -v -E 0x2000 -f bin -b /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: No such file or directory *** Error code 1 Stop in /scratch/freebsd/current/sys/boot/i386/boot2. *** Error code 1 I've seen this in the last couple of weeks as well. I build with -j3, and the buildworld seemed to go fine. During the installworld (after installkernel and reboot) I saw the same as you see. Running the make in the respective subdirectories, then rerunning installworld works. Example: btxld -v -E 0x2000 -f bin -b /usr/obj/scratch/freebsd/current/sys/boot/i386/zfsboot/../btx/btx/btx -l zfsboot.ldr -o zfsboot.ld -P 1 zfsboot.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=602c text=0 data=0 bss=0 entry=0 output: fmt=bin size=66bc text=0 data=66bc org=0 entry=0 6468 bytes available dd if=zfsboot.ld of=zfsboot2 obs=32768 conv=osync 51+1 records in 1+0 records out 32768 bytes transferred in 0.62 secs (528611360 bytes/sec) cat zfsboot1 zfsboot2 zfsboot ... and I fixed it in the same way. I'm assuming there's some dependency not listed in a makefile or something, but without the log from buildworld it's hard to find. Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Coming back to the btxld: No such file or directory installworld error
On Sun, Jun 27, 2010 at 11:27:41PM -0700, Garrett Cooper wrote: On Sun, Jun 27, 2010 at 10:54 PM, Ruslan Ermilov r...@freebsd.org wrote: On Sun, Jun 27, 2010 at 01:14:59PM -0700, Garrett Cooper wrote: Hi Ruslan, I've run into this particular error twice now in the past couple of weeks when building with -j24 on a memory disk and I was wondering if there was an missing dependency / race somewhere or something (perhaps make obj?): === sys/boot/i386/boot2 (install) # ... btxld -v -E 0x2000 -f bin -b /usr/obj/scratch/freebsd/current/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld: No such file or directory *** Error code 1 The install target isn't supposed to build stuff, only install it. When you see it trying to build something, this can be indicative of: - build wasn't run (e.g., after an update); Not the case (I ran buildworld and everything else up to that point installed happily). - a computer's date/time is set to the past (causing wrong date/time to be set on output files = causing them to be considered out-of- date by make(1)); check with date(1). My computer hasn't been time traveling lately :/ (If my calculations are correct, when this baby hits eighty-eight miles per hour... you're gonna see some serious shit.). - source files have modification times pointing to the future which fools make(1) into thinking that it should rebuild some target; check with find /usr/src -mtime -0. This seems unlikely as well. Did you actually check that? (Date/time on source files can be set by CVSup servers...) Is there a possibility that the existing Makefiles work by accident when -j 24 because the actions aren't executed in order :(? install isn't supposed to build stuff. The only exception I could remember of is timezone data files, plus some .db files. I strongly suggest checking the date/time of your computer and source files. If it's really okay, then check the following: run -j24 build, then run make -C /usr/src/sys/boot -nn -- if you see that it wants to build something, then this is a problem we should look into and try to fix. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic with zfs v16 patch
On 06/28/10 03:59, Sam Fourman Jr. wrote: hello list, I just had a panic on a FreeBSD 9.0 built with yesterdays sources. uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Sat Jun 26 09:14:30 CDT 2010 sfourman@:/usr/obj/usr/src/sys/ZFSv16 amd64 GENERIC kernel with this patch http://people.freebsd.org/~mm/patches/zfs/v16/head-v16-extended.patch i have a ufs2 boot drive with a separate ZFS pool since this was a fresh install of 9-current(specifically to test the v16 ZFS patches) I was doing a zpool import of a 2TB dataset that has ~100 snapshots it was taking over a hour to import, possibly this zfs bug http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6761786 So I decided to build subversion from ports while I waited on zfs import I got the panic in the following pics http://www.puffybsd.com/img_3995.jpg http://www.puffybsd.com/img_3996.jpg Curious - this panic is UFS softdep-related - possibly from the SUJ work? On which file system type is your ports tree? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Fri, Jun 25, 2010 at 11:47:59AM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: So, just for me to be clear, I need to proceed with the buildworld, until I get the error, and then, without cleaning anything, do % cd /usr/src % make buildenv % cd rescue/rescue % make Is that correct? Yes. Then you take the cc comand line that failed and run it again with the -v option and show us the output. ok, sorry, here it is. So starting with a clean src r209203 copy, and with /usr/obj/* wiped, make -j1 buildworld ends in cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' Then doing # make buildenv # cd rescue/rescue # make gives what looks like the same error message: cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' Finally repeating the last command with added -v flag gives: # cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo \ dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo \ ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo \ sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo \ ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo \ fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo \ kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo \ mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo \ mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: # cc -v -static -o rescue [...] cc: cat.lo: No such file or directory Umm, try again from the object directory, /usr/obj/usr/src/rescue/rescue/ # /usr/obj/usr/src/rescue/rescue/../librescue/exec.o: Permission denied That's weird, can you check the ownership of that file? Did you run buildworld as root and buildenv as a regular user? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Mon, Jun 28, 2010 at 02:38:10PM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: # cc -v -static -o rescue [...] cc: cat.lo: No such file or directory Umm, try again from the object directory, /usr/obj/usr/src/rescue/rescue/ that's better: # cd /usr/src/ # make buildenv Entering world for ia64:ia64 # cd /usr/obj/usr/src/rescue/rescue # pwd /usr/obj/usr/src/rescue/rescue # cat /usr/src/rescue/rescue/zzz cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/ escue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm # sh /usr/src/rescue/rescue/zzz Using built-in specs. Target: ia64-undermydesk-freebsd Configured with: FreeBSD/ia64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] /usr/obj/usr/src/tmp/usr/bin/ld -Bstatic -o rescue /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginT.o -L/usr/local/lib -L/usr/local/lib -L/us /obj/usr/src/tmp/usr/lib -L/usr/obj/usr/src/tmp/usr/lib rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpf .lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mo nt.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.l rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_ lass.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../libre cue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -l zma -larchive -lcrypto -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/obj/usr/src/tmp/usr/lib/crtend.o /usr/obj/usr/src/tmp/usr/lib/crtn.o xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' # /usr/obj/usr/src/rescue/rescue/../librescue/exec.o: Permission denied That's weird, can you check the ownership of that file? Did you run buildworld as root and buildenv as a regular user? # ls -al /usr/obj/usr/src/rescue/rescue/../librescue/exec.o -rw-r--r-- 1 root wheel 8256 28 Jun 11:57 /usr/obj/usr/src/rescue/rescue/../librescue/exec.o # no, both buildworld and buildenv are run as root. thank you anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/ escue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm Look again, your command line is mangled. For instance, the r in realpath.lo is missing and the l in fsck_ffs.lo has been replaced with a space. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: 86mxuf7eli@ds4.des.no
Dag-Erling Smørgrav d...@des.no writes:
: M. Warner Losh i...@bsdimp.com writes:
: Why not fix pidfile_open to not return a file handle when the PID
: doesn't match?
:
: It doesn't. If it can't lock the file, or if fstat(2) fails after it
: has locked the file, it returns NULL.
Then we have a bug in the locking code. I've definitely seen things
fail to behave properly after killing devd. Let me trace out what I
think is going on:
From pidfile_open:
/*
* Open the PID file and obtain exclusive lock.
* We truncate PID file here only to remove old PID immediatelly,
* PID file will be truncated again in pidfile_write(), so
* pidfile_write() can be called multiple times.
*/
fd = flopen(pfh-pf_path,
O_WRONLY | O_CREAT | O_TRUNC | O_NONBLOCK, mode);
if (fd == -1) {
--- We take this path, fd == -1.
count = 0;
rqtp.tv_sec = 0;
rqtp.tv_nsec = 500;
if (errno == EWOULDBLOCK pidptr != NULL) {
again:
--- and this one, so errno is EWOULDBLOCK
errno = pidfile_read(pfh-pf_path, pidptr);
--- errno is 0 here, so
if (errno == 0)
errno = EEXIST;
--- We return NULL with errno set toEEXIST
else if (errno == EAGAIN) {
if (++count = 3) {
nanosleep(rqtp, 0);
goto again;
}
}
}
free(pfh);
return (NULL);
}
So what's going on?
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: 86iq537egy@ds4.des.no Dag-Erling Smørgrav d...@des.no writes: : M. Warner Losh i...@bsdimp.com writes: : Maybe the real problem is that devd locks the file, then dies. The : file remains locked, so the flopen is failing with EWOULDBLOCK. : : The lock is released when the process that holds it terminates. So which process is that? devd took it out, and is subsequently killed. When it restarts, it can't take out the lock. The same code works perfectly in 8.0-stable from April. The conclusion, I believe, is that somebody broke locking in current... grump Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktiki223vbybdeqlua6fjcbbeqcqfujoimp5ho...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Sun, Jun 27, 2010 at 3:08 PM, M. Warner Losh i...@bsdimp.com wrote:
: In message: aanlktilnygnz7v6z6akeksquvomn8ylvo57gm1goi...@mail.gmail.com
: Garrett Cooper yanef...@gmail.com writes:
: : On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper yanef...@gmail.com
wrote:
: : On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
: : Hi,
: :
: : Sometimes utilities that are started by devd require libraries outside
: : /usr/lib. One example is the webcamd utility which is started by devd
upon USB
: : device insertion. What do you think about the following patch:
: :
: : --- devd (revision 209463)
: : +++ devd (local)
: : @@ -4,7 +4,7 @@
: : #
: :
: : # PROVIDE: devd
: : -# REQUIRE: netif
: : +# REQUIRE: netif ldconfig
: : # BEFORE: NETWORKING mountcritremote
: : # KEYWORD: nojail shutdown
: :
: : Funny since I was just monkeying around with this. This doesn't appear
: : to be the only issue with devd:
: :
: : # devd
: : devd: devd already running, pid: 430
: : # pgrep 430; echo $?
: : 1
: : #
: :
: : Looks like /etc/rc.d/devd restart is broken :(...
: :
: : This seems to fix that.
: : Thanks,
: : -Garrett
: :
: : Index: devd.cc
: : ===
: : --- devd.cc (revision 209530)
: : +++ devd.cc (working copy)
: : @@ -739,6 +739,7 @@
: : static void
: : event_loop(void)
: : {
: : + bool warn_user_about_cleanup;
: : int rv;
: : int fd;
: : char buffer[DEVCTL_MAXBUF];
: : @@ -804,6 +805,17 @@
: : new_client(server_fd);
: : }
: : close(fd);
: : + close(server_fd);
: : +
: : + if (unlink(PIPE) == 0) {
: : + cfg.remove_pidfile();
: : + warn_user_about_cleanup = false;
: : + } else
: : + warn_user_about_cleanup = true;
: : +
: : + if (warn_user_about_cleanup == true)
: : + warn(cleanup failed);
: : +
: : }
: :
: : /*
:
: This patch is wrong. The problems with it:
:
: (1) You don't need to unlink the pipe. If you can't unlink it, then
: you won't remove the pid file.
: (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
: remain around, and devd will fail to start.
: (3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed.
:
: The following works around the bug in pidfile_open, and allows me to
: restart devd both in a nice shutdown mode, as well as preventing devd
: from running multiple times. I'm not 100% sure the error handling is
: right, I'm still tracing through that path. This seems to work.
:
: Warner
:
: Index: devd.cc
: ===
: --- devd.cc (revision 209492)
: +++ devd.cc (working copy)
: @@ -376,11 +376,18 @@
: if (_pidfile == )
: return;
: pfh = pidfile_open(_pidfile.c_str(), 0600, otherpid);
: - if (pfh == NULL) {
: - if (errno == EEXIST)
: + if (pfh != NULL)
: + return;
: + if (errno == EEXIST) {
: + /*
: + * Work around a bug in libutil where it will return this
: + * condition when the other process does not, in fact,
: + * actually exist. Use kill(2) to see if it is there or
not.
: + */
: + if (kill(otherpid, 0) == 0)
: errx(1, devd already running, pid: %d,
(int)otherpid);
: + } else
: warn(cannot open pid file);
: - }
: }
:
: void
: @@ -804,6 +811,8 @@
: new_client(server_fd);
: }
: close(fd);
: + close(server_fd);
: + cfg.remove_pidfile();
: }
:
: I see what you mean. pidfile_open obviously fails with this requirement:
:
: If a file can not be locked, a PID of an already running daemon is
returned
: in the pidptr argument (if it is not NULL). The function does not write
: process' PID into the file here, so it can be used before
: fork()ing and exit
: with a proper error message when needed. If the path argument is NULL,
: /var/run/progname.pid file will be used.
:
: The problem I think is that the flopen arguments are wrong -- it passes in
: O_TRUNC, instead of checking whether or not the file exists beforehand, and
: then attempt to read in the file (if it exists) to determine whether
: or not the PID is alive.
Apart from tidiness, my patch is bogus. The real problem is flock()
seems to be failing now. Tests of my 8.0-stable system from April
shows that it works there. Likewise, my -current system from Jan 21st
appears to work. Time to start the binary search.
Warner
Re: Patch for rc.d/devd on FreeBSD 9-current
M. Warner Losh i...@bsdimp.com writes: Dag-Erling Smørgrav d...@des.no writes: M. Warner Losh i...@bsdimp.com writes: Maybe the real problem is that devd locks the file, then dies. The file remains locked, so the flopen is failing with EWOULDBLOCK. The lock is released when the process that holds it terminates. So which process is that? devd took it out, and is subsequently killed. When it restarts, it can't take out the lock. What does fstat say about the pid file? The same code works perfectly in 8.0-stable from April. The conclusion, I believe, is that somebody broke locking in current... Before I wrote one of my earlier replies, I traced through the code paths that lead to a lock being released, and everything looks fine and dandy. Besides, if someone had, as you suggest, broken locking in current, there would be a lot more noise about it on the lists. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic with zfs v16 patch
Curious - this panic is UFS softdep-related - possibly from the SUJ work? On which file system type is your ports tree? ufs2 -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic with zfs v16 patch
On Mon, Jun 28, 2010 at 9:43 AM, Sam Fourman Jr. sfour...@gmail.com wrote: Curious - this panic is UFS softdep-related - possibly from the SUJ work? On which file system type is your ports tree? ufs2 it seems ivan may be correct, I went and tried to continue the subversion build I received this panic, while downloading a file (I was doing nothing with ZFS at all this time) === License check disabled, port has not defined LICENSE === Found saved configuration for postgresql-client-8.2.17_1 = postgresql-8.2.17.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/postgresql. = Attempting to fetch from ftp://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.17/. postgresql-8.2.17.tar.bz2 52% of 12 MB 855 kBps http://www.puffybsd.com/img_3997.jpg http://www.puffybsd.com/img_3999.jpg any other useful data I can gather? -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Mon, Jun 28, 2010 at 03:58:35PM +0200, Dag-Erling Smørgrav wrote: Anton Shterenlikht me...@bristol.ac.uk writes: cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chr oot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/ escue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm Look again, your command line is mangled. For instance, the r in realpath.lo is missing and the l in fsck_ffs.lo has been replaced with a space. I think this only happens when I copy from one xterm to another, to paste into the mailer. I've checked the command which I put in a file, and all seems fine. Also, the latest error message suggests that the command is fine: # cat /usr/src/rescue/rescue/zzz cc -v -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo ealpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs. o fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msd sfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.l spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/ escue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lk m -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm # sh /usr/src/rescue/rescue/zzz Using built-in specs. Target: ia64-undermydesk-freebsd Configured with: FreeBSD/ia64 system compiler Thread model: posix gcc version 4.2.1 20070719 [FreeBSD] /usr/obj/usr/src/tmp/usr/bin/ld -Bstatic -o rescue /usr/obj/usr/src/tmp/usr/lib/crt1.o /usr/obj/usr/src/tmp/usr/lib/crti.o /usr/obj/usr/src/tmp/usr/lib/crtbeginT.o -L/usr/local/lib -L/usr/local/lib -L/us /obj/usr/src/tmp/usr/lib -L/usr/obj/usr/src/tmp/usr/lib rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpf .lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mo nt.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo
Re: panic with zfs v16 patch
On 06/28/10 17:20, Sam Fourman Jr. wrote: On Mon, Jun 28, 2010 at 9:43 AM, Sam Fourman Jr. sfour...@gmail.com wrote: Curious - this panic is UFS softdep-related - possibly from the SUJ work? On which file system type is your ports tree? ufs2 it seems ivan may be correct, I went and tried to continue the subversion build I received this panic, while downloading a file (I was doing nothing with ZFS at all this time) === License check disabled, port has not defined LICENSE === Found saved configuration for postgresql-client-8.2.17_1 = postgresql-8.2.17.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/postgresql. = Attempting to fetch from ftp://ftp9.us.postgresql.org/pub/mirrors/postgresql/source/v8.2.17/. postgresql-8.2.17.tar.bz2 52% of 12 MB 855 kBps http://www.puffybsd.com/img_3997.jpg http://www.puffybsd.com/img_3999.jpg any other useful data I can gather? READ_DMA and WRITE_DMA errors usually indicate that your disk has bad sectors or has become broken, but you have so many of them on multiple drives (ad4, ad8, ad10), which might mean your disk controller is dying or you have really bad cabling in the machine. You might try using something like # dd if=/dev/ad8 of=/dev/null bs=1m to see if you can reliably provoke errors on the same part of the disk - if not, there is certainly a problem with the controller or cabling; if yes, it can also be a disk problem. In any case, it looks like your problem is not related to any file system code. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic in deadlkres
On Friday 25 June 2010 4:52:22 pm pluknet wrote:
On 25 June 2010 13:50, Anton Yuzhaninov cit...@citrin.ru wrote:
I've got panic on 9-current from Jun 25 2010
May be this is bug in deadlock resolver
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/kern/kern_clock.c:203
db show alllocks
Process 0 (kernel) thread 0xc4dcd270 (100047)
shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
/usr/src/sys/kern/kern_clock.c:193
db show lock 0xc4dcd270
class: spin mutex
name: D
flags: {SPIN, RECURSE}
state: {OWNED}
(kgdb) bt
#0 doadump () at pcpu.h:248
#1 0xc05ae59f in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ae825 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc048ff45 in db_panic (addr=Could not find the frame base for
db_panic.
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:445
#5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc04923ef in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_main.c:229
#7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc078696b in trap (frame=0xc4b31bd0) at
/usr/src/sys/i386/i386/trap.c:692
#9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc05daf30 in kdb_enter (why=0xc07ea02d panic, msg=0xc07ea02d
panic) at cpufunc.h:71
#11 0xc05ae806 in panic (fmt=0xc07efd94 blockable sleep lock (%s) %s @
%s:%d) at /usr/src/sys/kern/kern_shutdown.c:573
#12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9,
file=0xc07e3b20 /usr/src/sys/kern/kern_clock.c, line=203, interlock=0x0)
at /usr/src/sys/kern/subr_witness.c:1067
#13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203)
at /usr/src/sys/kern/kern_mutex.c:200
#14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#15 0xc0588721 in fork_exit (callout=0xc05705ea deadlkres, arg=0x0,
frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843
#16 0xc076ca80 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:270
Hi!
[throw in ideas (just ignore them if they're dumb, thinking badly atm).]
AFAIK, that indicates that some thread already has
a spin mutex and then it tries to acquire a sleep mutex.
Looks like kern/kern_clock.c v1.213 (SVN rev 206482)
has a regression in handling ticks wrap-up
w.r.t. it doesn't release a thread mutex, does it?
This looks like a correct analysis to me.
From subr_witness.c:
1062: * Since spin locks include a critical section, this
check
1063: * implicitly enforces a lock order of all sleep
locks before
1064: * all spin locks.
1065: */
1066:if (td-td_critnest != 0 !kdb_active)
1067:panic(blockable sleep lock (%s) %s @ %s:%d,
1068:class-lc_name, lock-lo_name, file, line);
From kern_clock.c, v1.213 (in several places, while holding a thread lock):
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick)
+ continue;
Should not it be like the next:
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick) {
+ thread_unlock(td);
+ continue;
+ }
The precondition idea to reproduce it is to lock a subject thread
in some deadlkres callout, handle re-wrap condition, then try
to lock a process to witch the thread belongs in (n+m)'th deadlkres
callout, or in different context.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[sparc64] [panic] cheetah_ipi_selected: CPU can't IPI itself
Well, I'm back in the same town as my sparc64 and so csup'd, built, and rebooted, trying to get more information about the vm object not owned panic I reported a while ago. To my dismay, I now get this panic, also late enough in the boot process to be starting up jails: panic: cheetah_ipi_selected: CPU can't IPI itself cpuid = 0 KDB: stack backtrace: panic() at panic+0x1c8 cheetah_ipi_selected() at cheetah_ipi_selected+0x48 tlb_page_demap() at tlb_page_demap+0xdc pmap_copy_page() at pmap_copy_page+0x4c4 vm_fault() at vm_fault+0x13ec trap_pfault() at trap_pfault+0x190 trap() at trap+0xd0 -- data access protection tar=0x224b93 sfar=0x224550 sfsr=0x85 %o7=0x4063398c -- userland() at 0x40633830 user trace: trap %o7=0x4063398c ... And the system hangs; I had to use the ALOM to reboot it. Sorry to not have more useful news. --nwf; pgpdTuFjRko2M.pgp Description: PGP signature
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: I think this only happens when I copy from one xterm to another, to paste into the mailer. I've checked the command which I put in a file, and all seems fine. Also, the latest error message suggests that the command is fine: OK, can you do it again with -Wl,--verbose in addition to -v? Like this: cc -static -v -Wl,--verbose -o rescue ... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
2010/6/28 Dag-Erling Smørgrav d...@des.no: M. Warner Losh i...@bsdimp.com writes: Dag-Erling Smørgrav d...@des.no writes: M. Warner Losh i...@bsdimp.com writes: Maybe the real problem is that devd locks the file, then dies. The file remains locked, so the flopen is failing with EWOULDBLOCK. The lock is released when the process that holds it terminates. So which process is that? devd took it out, and is subsequently killed. When it restarts, it can't take out the lock. What does fstat say about the pid file? The same code works perfectly in 8.0-stable from April. The conclusion, I believe, is that somebody broke locking in current... Before I wrote one of my earlier replies, I traced through the code paths that lead to a lock being released, and everything looks fine and dandy. Besides, if someone had, as you suggest, broken locking in current, there would be a lot more noise about it on the lists. Hi DES, When I do the following: /etc/rc.d/devd start /etc/rc.d/devd stop It leaves stray unused lockfiles in the directory: $ sudo /etc/rc.d/devd start Starting devd. $ ls -l /var/run/devd.pi* -rw--- 1 root wheel 5 Jun 28 09:53 /var/run/devd.pid srw-rw-rw- 1 root wheel 0 Jun 28 09:53 /var/run/devd.pipe $ fstat /var/run/devd.pi* USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME root devd 297916 /var 447511 -rw--- 5 w /var/run/devd.pid $ sudo /etc/rc.d/devd stop Stopping devd. $ ls -l /var/run/devd.pi* -rw--- 1 root wheel 5 Jun 28 09:52 /var/run/devd.pid srw-rw-rw- 1 root wheel 0 Jun 28 09:52 /var/run/devd.pipe $ fstat /var/run/devd.pi* USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
On Sun, Jun 27, 2010 at 3:08 PM, M. Warner Losh i...@bsdimp.com wrote:
In message: aanlktilnygnz7v6z6akeksquvomn8ylvo57gm1goi...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: On Sat, Jun 26, 2010 at 1:45 PM, Garrett Cooper yanef...@gmail.com wrote:
: On Sat, Jun 26, 2010 at 1:29 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
: Hi,
:
: Sometimes utilities that are started by devd require libraries outside
: /usr/lib. One example is the webcamd utility which is started by devd
upon USB
: device insertion. What do you think about the following patch:
:
: --- devd (revision 209463)
: +++ devd (local)
: @@ -4,7 +4,7 @@
: #
:
: # PROVIDE: devd
: -# REQUIRE: netif
: +# REQUIRE: netif ldconfig
: # BEFORE: NETWORKING mountcritremote
: # KEYWORD: nojail shutdown
:
: Funny since I was just monkeying around with this. This doesn't appear
: to be the only issue with devd:
:
: # devd
: devd: devd already running, pid: 430
: # pgrep 430; echo $?
: 1
: #
:
: Looks like /etc/rc.d/devd restart is broken :(...
:
: This seems to fix that.
: Thanks,
: -Garrett
:
: Index: devd.cc
: ===
: --- devd.cc (revision 209530)
: +++ devd.cc (working copy)
: @@ -739,6 +739,7 @@
: static void
: event_loop(void)
: {
: + bool warn_user_about_cleanup;
: int rv;
: int fd;
: char buffer[DEVCTL_MAXBUF];
: @@ -804,6 +805,17 @@
: new_client(server_fd);
: }
: close(fd);
: + close(server_fd);
: +
: + if (unlink(PIPE) == 0) {
: + cfg.remove_pidfile();
: + warn_user_about_cleanup = false;
: + } else
: + warn_user_about_cleanup = true;
: +
: + if (warn_user_about_cleanup == true)
: + warn(cleanup failed);
: +
: }
:
: /*
This patch is wrong. The problems with it:
(1) You don't need to unlink the pipe. If you can't unlink it, then
you won't remove the pid file.
The reason why my previous patch deleted `PIPE' file was because it's
not a true pipe, but instead a named file in the filesystem, as that
never gets cleaned up otherwise (please see my latest post).
(2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
remain around, and devd will fail to start.
Correct.
(3) i_really_do_not_like_names_this_long_esp_when_they_are_not_needed.
Fair enough :D.
The following works around the bug in pidfile_open, and allows me to
restart devd both in a nice shutdown mode, as well as preventing devd
from running multiple times. I'm not 100% sure the error handling is
right, I'm still tracing through that path. This seems to work.
Thanks!
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
In message: aanlktimpbazy2gu8fsly6wqdyzvg7c0id-vzeh3a3...@mail.gmail.com
Garrett Cooper yanef...@gmail.com writes:
: This patch is wrong. The problems with it:
:
: (1) You don't need to unlink the pipe. If you can't unlink it, then
: you won't remove the pid file.
:
: The reason why my previous patch deleted `PIPE' file was because it's
: not a true pipe, but instead a named file in the filesystem, as that
: never gets cleaned up otherwise (please see my latest post).
That's Ok. The problem is elsewhere. The PIPE should not be deleted,
since that introduces races with other programs wishing to listen to
the pipe.
: (2) If devd dies suddenly (kill -9, segv, etc), then the pid file will
: remain around, and devd will fail to start.
:
: Correct.
Not quite. The pid file doesn't prevent devd starting. The lock on
the pid file does.
Why is the pid file still locked? Is locking broken in current? (no,
it isn't: all relevant regression tests pass) What is the root cause
then?
For me, devd refused to start because it exec'd dhclient. dhclient
survived having devd die. devd didn't close the lock file fd, so
dhclient inherited it.
My first knee-jerk reaction was 'why isn't that close on exec?'
That's a good question, the short answer of which is 'because there
are times you don't want it to be.'
But even that's not the root cause. Why is devd using system(3) to
execute commands? Why isn't it taking more care to create a cleaner
environment for commands to execute in? why isn't it following the
advice in the pidfile_close man page? These are all good questions.
Also, why do the child processes get an fd to read the stream of
events from the kernel on? Isn't that an information leak?
So, I've copied system and added the proper calls to clean all this
up.
Sadly, this only addresses the complaint that Garrett brought up. It
doesn't address the legitimate concerns that Hans has about startup
sequence and races with mounting /usr/local. That's a very good
question, indeed. You want to defer some actions until other services
are available. In a launchd world, you fork and run the processes.
They use whatever resources they need, but block on resources that
haven't finished starting yet. That's one possible solution here, but
outside the scope of devd, I'm afraid...
Warner
Index: devd.hh
===
--- devd.hh (revision 209492)
+++ devd.hh (working copy)
@@ -153,6 +153,7 @@
void set_pidfile(const char *);
void reset();
void parse();
+ void close_pidfile();
void open_pidfile();
void write_pidfile();
void remove_pidfile();
Index: devd.cc
===
--- devd.cc (revision 209492)
+++ devd.cc (working copy)
@@ -41,6 +41,7 @@
#include sys/stat.h
#include sys/sysctl.h
#include sys/types.h
+#include sys/wait.h
#include sys/un.h
#include ctype.h
@@ -49,6 +50,7 @@
#include err.h
#include fcntl.h
#include libutil.h
+#include paths.h
#include regex.h
#include signal.h
#include stdlib.h
@@ -152,13 +154,67 @@
// nothing
}
+static int
+my_system(const char *command)
+{
+ pid_t pid, savedpid;
+ int pstat;
+ struct sigaction ign, intact, quitact;
+ sigset_t newsigblock, oldsigblock;
+
+ if (!command) /* just checking... */
+ return(1);
+
+ /*
+* Ignore SIGINT and SIGQUIT, block SIGCHLD. Remember to save
+* existing signal dispositions.
+*/
+ ign.sa_handler = SIG_IGN;
+ ::sigemptyset(ign.sa_mask);
+ ign.sa_flags = 0;
+ ::sigaction(SIGINT, ign, intact);
+ ::sigaction(SIGQUIT, ign, quitact);
+ ::sigemptyset(newsigblock);
+ ::sigaddset(newsigblock, SIGCHLD);
+ ::sigprocmask(SIG_BLOCK, newsigblock, oldsigblock);
+ switch(pid = ::fork()) {
+ case -1:/* error */
+ break;
+ case 0: /* child */
+ /*
+* Restore original signal dispositions and exec the command.
+*/
+ ::sigaction(SIGINT, intact, NULL);
+ ::sigaction(SIGQUIT, quitact, NULL);
+ ::sigprocmask(SIG_SETMASK, oldsigblock, NULL);
+ /*
+* Close the PID file, and all other open descriptors.
+* Inherit std{in,out,err} only.
+*/
+ cfg.close_pidfile();
+ ::closefrom(3);
+ ::execl(_PATH_BSHELL, sh, -c, command, (char *)NULL);
+ ::_exit(127);
+ default:/* parent */
+ savedpid = pid;
+ do {
+ pid = ::wait4(savedpid, pstat, 0, (struct rusage *)0);
+ } while (pid == -1 errno == EINTR);
+ break;
+ }
+
Re: panic in deadlkres
2010/6/28 John Baldwin j...@freebsd.org:
On Friday 25 June 2010 4:52:22 pm pluknet wrote:
On 25 June 2010 13:50, Anton Yuzhaninov cit...@citrin.ru wrote:
I've got panic on 9-current from Jun 25 2010
May be this is bug in deadlock resolver
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/kern/kern_clock.c:203
db show alllocks
Process 0 (kernel) thread 0xc4dcd270 (100047)
shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
/usr/src/sys/kern/kern_clock.c:193
db show lock 0xc4dcd270
class: spin mutex
name: D
flags: {SPIN, RECURSE}
state: {OWNED}
(kgdb) bt
#0 doadump () at pcpu.h:248
#1 0xc05ae59f in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ae825 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc048ff45 in db_panic (addr=Could not find the frame base for
db_panic.
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0,
dopager=1) at /usr/src/sys/ddb/db_command.c:445
#5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc04923ef in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_main.c:229
#7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc078696b in trap (frame=0xc4b31bd0) at
/usr/src/sys/i386/i386/trap.c:692
#9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc05daf30 in kdb_enter (why=0xc07ea02d panic, msg=0xc07ea02d
panic) at cpufunc.h:71
#11 0xc05ae806 in panic (fmt=0xc07efd94 blockable sleep lock (%s) %s @
%s:%d) at /usr/src/sys/kern/kern_shutdown.c:573
#12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9,
file=0xc07e3b20 /usr/src/sys/kern/kern_clock.c, line=203, interlock=0x0)
at /usr/src/sys/kern/subr_witness.c:1067
#13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203)
at /usr/src/sys/kern/kern_mutex.c:200
#14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#15 0xc0588721 in fork_exit (callout=0xc05705ea deadlkres, arg=0x0,
frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843
#16 0xc076ca80 in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:270
Hi!
[throw in ideas (just ignore them if they're dumb, thinking badly atm).]
AFAIK, that indicates that some thread already has
a spin mutex and then it tries to acquire a sleep mutex.
Looks like kern/kern_clock.c v1.213 (SVN rev 206482)
has a regression in handling ticks wrap-up
w.r.t. it doesn't release a thread mutex, does it?
This looks like a correct analysis to me.
From subr_witness.c:
1062: * Since spin locks include a critical section, this
check
1063: * implicitly enforces a lock order of all sleep
locks before
1064: * all spin locks.
1065: */
1066: if (td-td_critnest != 0 !kdb_active)
1067: panic(blockable sleep lock (%s) %s @ %s:%d,
1068: class-lc_name, lock-lo_name, file, line);
From kern_clock.c, v1.213 (in several places, while holding a thread lock):
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick)
+ continue;
Should not it be like the next:
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick) {
+ thread_unlock(td);
+ continue;
+ }
The precondition idea to reproduce it is to lock a subject thread
in some deadlkres callout, handle re-wrap condition, then try
to lock a process to witch the thread belongs in (n+m)'th deadlkres
callout, or in different context.
Thanks, that may be fixed in r209577.
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
Garrett Cooper yanef...@gmail.com writes: It leaves stray unused lockfiles in the directory: That's normal and harmless. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
2010/6/28 Dag-Erling Smørgrav d...@des.no: Garrett Cooper yanef...@gmail.com writes: It leaves stray unused lockfiles in the directory: That's normal and harmless. Yeah.. it's just a bit messy :D. Thanks for the help! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
On Sat, Jun 26, 2010 at 10:50 PM, Doug Barton do...@freebsd.org wrote: On 06/26/10 13:29, Hans Petter Selasky wrote: Hi, Sometimes utilities that are started by devd require libraries outside /usr/lib. One example is the webcamd utility which is started by devd upon USB device insertion. What do you think about the following patch: --- devd (revision 209463) +++ devd (local) @@ -4,7 +4,7 @@ # # PROVIDE: devd -# REQUIRE: netif +# REQUIRE: netif ldconfig # BEFORE: NETWORKING mountcritremote # KEYWORD: nojail shutdown ldconfig requires mountcritremote, so this patch would introduce a circular dependency. Should ldconfig require mountcritlocal instead? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Patch for rc.d/devd on FreeBSD 9-current
On Mon, 28 Jun 2010, Garrett Cooper wrote: On Sat, Jun 26, 2010 at 10:50 PM, Doug Barton do...@freebsd.org wrote: On 06/26/10 13:29, Hans Petter Selasky wrote: Hi, Sometimes utilities that are started by devd require libraries outside /usr/lib. One example is the webcamd utility which is started by devd upon USB device insertion. What do you think about the following patch: --- devd (revision 209463) +++ devd (local) @@ -4,7 +4,7 @@ # # PROVIDE: devd -# REQUIRE: netif +# REQUIRE: netif ldconfig # BEFORE: NETWORKING mountcritremote # KEYWORD: nojail shutdown ldconfig requires mountcritremote, so this patch would introduce a circular dependency. Should ldconfig require mountcritlocal instead? The operating theory is that we want to provide robust support for /usr/local not mounted locally. (And yes, I get the irony there.) :) What could be done is a 2-pass ldconfig, as is done for some other services. However if I understood the OP's problem correctly, that may not help here because devd is trying to start something that is in /usr/local. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
