daily CVS update output
Updating src tree: P src/etc/rc.d/dhcpcd P src/lib/libcurses/toucholap.c P src/sbin/newfs_msdos/mkfs_msdos.h P src/sys/arch/arm/allwinner/awin_mmc.c P src/usr.sbin/makefs/msdos.c P src/usr.sbin/makefs/msdos.h Updating xsrc tree: Killing core files: Updating tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting...pax: Unable to access src/x11 (No such file or directory) pax: WARNING! These file names were not selected: src/x11 done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting...pax: Unable to access xsrc/xfree (No such file or directory) pax: WARNING! These file names were not selected: xsrc/xfree done xsrc: collecting... replacing... done Running the SUP scanner: SUP Scan for current starting at Sat Oct 17 03:23:42 2015 SUP Scan for current completed at Sat Oct 17 03:27:15 2015 SUP Scan for mirror starting at Sat Oct 17 03:27:15 2015 SUP Scan for mirror completed at Sat Oct 17 03:30:43 2015 Updating release-5 src tree (netbsd-5): Updating release-5 xsrc tree (netbsd-5): Updating release-5 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: collecting... replacing... done src/config: collecting... replacing... done src/x11: collecting... replacing... done src: collecting... replacing... done xsrc/top-level: collecting... replacing... done xsrc/local: collecting... replacing... done xsrc/xfree: collecting... replacing... done xsrc/external: collecting... replacing... done xsrc: collecting... replacing... done Running the SUP scanner: SUP Scan for release-5 starting at Sat Oct 17 03:48:50 2015 SUP Scan for release-5 completed at Sat Oct 17 03:48:56 2015 Updating release-6 src tree (netbsd-6): Updating release-6 xsrc tree (netbsd-6): Updating release-6 tar files: src/top-level: collecting... replacing... done src/bin: collecting... replacing... done src/common: collecting... replacing... done src/compat: collecting... replacing... done src/crypto: collecting... replacing... done src/dist: collecting... replacing... done src/distrib: collecting... replacing... done src/doc: collecting... replacing... done src/etc: collecting... replacing... done src/external: collecting... replacing... done src/extsrc: collecting... replacing... done src/games: collecting... replacing... done src/gnu: collecting... replacing... done src/include: collecting... replacing... done src/lib: collecting... replacing... done src/libexec: collecting... replacing... done src/regress: collecting... replacing... done src/rescue: collecting... replacing... done src/sbin: collecting... replacing... done src/share: collecting... replacing... done src/sys: collecting... replacing... done src/tests: collecting... replacing... done src/tools: collecting... replacing... done src/usr.bin: collecting... replacing... done src/usr.sbin: coll
Re: Finding the current drive devices
On Fri, Oct 16, 2015 at 02:02:45PM -0400, D'Arcy J.M. Cain wrote: > > Not sure that that helps. Won't wedges on different servers still have > different names? The goal is to use exactly the same fstab file on > disparate hardware. With gpt yes, you could just use the same naming scheme. With disklabel you need the same partitioning scheme because the partition letter is part of the wedge name. But in your case that's probably given. Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Finding the current drive devices
On Fri, 16 Oct 2015 17:48:29 + (UTC) mlel...@serpens.de (Michael van Elst) wrote: > da...@netbsd.org ("D'Arcy J.M. Cain") writes: > > >I also have to figure out how to deal with hard drive differences in > >fstab but I don't have a clue how to proceed with that problem. > > Use named wedges. Not sure that that helps. Won't wedges on different servers still have different names? The goal is to use exactly the same fstab file on disparate hardware. I wonder if putting both in the same file would work. One will work and the other will fail. -- D'Arcy J.M. Cain http://www.NetBSD.org/ IM:da...@vex.net
Re: Finding the current network devices
da...@netbsd.org ("D'Arcy J.M. Cain") writes: >I also have to figure out how to deal with hard drive differences in >fstab but I don't have a clue how to proceed with that problem. Use named wedges. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Finding the current network devices
Obviously "ifconfig -l" gets the info but I was wondering if I could depend on the order that is returned. Here's my problem and my proposed solution. I have a bunch of servers all running NetBSD running various services. While I tend to run Proliant servers for everything, there is more than one generation in the mix. Sometimes the cards are wm[01] and sometimes bge[01] for example. If I need to move a service over to the spare I make sure that all the files, including rc.conf, etc. are mirrored using rsync and then reboot. If I forget to adjust the network cards I am locked out until I go to the server room. My solution is to add this to the top of rc.conf: read eth0 eth1 _ <<< `ifconfig -l` And then use $eth0 and $eth1 in the ifconfig lines and elsewhere. My question is whether the ifconfig command is guaranteed to always return the ethernet cards first, e.g. "wm0 wm1 lo0 pflog0" or "bge0 bge1 lo0 pflog0" as the case may be. If I add the -b option would that be safer? I also have to figure out how to deal with hard drive differences in fstab but I don't have a clue how to proceed with that problem. Cheers. -- D'Arcy J.M. Cain http://www.NetBSD.org/ IM:da...@vex.net
Re: Killing a zombie process?
On Fri 16 Oct 2015 at 16:29:55 +0200, J. Hannken-Illjes wrote: > Looks like we are waiting for a NFS operation to complete. > > Did the machine hang here? No, but I didn't try specifically to access the nfs volumes. Interestingly enough, after the reboot (which used the stock 7.0 GENERIC kernel) I'm back at a hanging build, at a point which even more points to NFS: 13:02 cd /usr/pkgsrc/print/teTeX3-texmf && /usr/bin/make update CLEANDEPENDS=yes ===> do-bin-install [teTeX-texmf-3.0nb56] ===> Binary install for teTeX-texmf-3.0nb56 => Installing teTeX-texmf-3.0nb56 from /pkg_comp/packages/All pkg_add: no pkg found for 'teTeX-texmf-3.0nb56', sorry. pkg_add: 1 package addition failed => No binary package found for teTeX-texmf-3.0nb56; installing from source. load: 1.00 cmd: sh 22134 [wait] 0.00u 0.00s 0% 1424k make[1]: Working in: /usr/pkgsrc/print/teTeX3-texmf make: Working in: /usr/pkgsrc/print/teTeX3-texmf make[2]: Working in: /usr/pkgsrc/print/teTeX3-texmf load: 1.00 cmd: sh 22134 [wait] 0.00u 0.00s 0% 1424k make[1]: Working in: /usr/pkgsrc/print/teTeX3-texmf make: Working in: /usr/pkgsrc/print/teTeX3-texmf make[2]: Working in: /usr/pkgsrc/print/teTeX3-texmf load: 0.03 cmd: sh 22134 [wait] 0.00u 0.00s 0% 1424k make[2]: Working in: /usr/pkgsrc/print/teTeX3-texmf make: Working in: /usr/pkgsrc/print/teTeX3-texmf make[1]: Working in: /usr/pkgsrc/print/teTeX3-texmf and no process in tstile. But now I am trying to access all the NFS mounts and they all manage to do at least an ls and du (at least for a few seconds until interrupted). Now I'm interrupting the make, which gives me a shell prompt back but not all is working: ^C pkg_comp:default70.conf# pkg_comp:default70.conf# pkg_comp:default70.conf# cd usr/pkgsrc/print/teTeX3-texmf pkg_comp:default70.conf# make clean load: 0.78 cmd: sh 28490 [wait] 0.00u 0.00s 0% 1424k make: Working in: /usr/pkgsrc/print/teTeX3-texmf The full du I was doing for the mount of /usr/pkgsrc is now also stalled. I think we can conclude from this that indeed it is some NFS problem. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgp1LAPQggHie.pgp Description: PGP signature
Re: Killing a zombie process?
On Fri 16 Oct 2015 at 16:31:18 +0200, J. Hannken-Illjes wrote: > On 16 Oct 2015, at 13:44, Rhialto wrote: > > > On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote: > >> On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote: > >>> Do you really need that mounted twice like that, and if not, can you try > >>> with one of them missing and see if the problem remains ? > >> > >> Good idea, I'll try that later! > > > > "Interesting" results: it built packages overnight (from around 22:30 to > > 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted. > > With panic? This was logged; for some reason savecore claims there is no dump though. Oct 15 19:47:32 vargaz /netbsd: NetBSD 7.99.21 (GENERIC) #1: Wed Oct 14 01:52:52 CEST 2015 Oct 16 12:15:16 vargaz syslogd[798]: restart Oct 16 12:15:16 vargaz /netbsd: fatal page fault in supervisor mode Oct 16 12:15:16 vargaz /netbsd: trap type 6 code 0 rip 80714eed cs 8 rflags 10246 cr2 38 ilevel 2 rsp fe80b9fc6f10 Oct 16 12:15:16 vargaz /netbsd: curlwp 0xfe813fb34860 pid 0.5 lowest kstack 0xfe80b9fc32c0 Oct 16 12:15:16 vargaz /netbsd: panic: trap Oct 16 12:15:16 vargaz /netbsd: cpu0: Begin traceback... Oct 16 12:15:16 vargaz /netbsd: vpanic() at netbsd:vpanic+0x13c Oct 16 12:15:16 vargaz /netbsd: snprintf() at netbsd:snprintf Oct 16 12:15:16 vargaz /netbsd: startlwp() at netbsd:startlwp Oct 16 12:15:16 vargaz /netbsd: alltraps() at netbsd:alltraps+0x9e Oct 16 12:15:16 vargaz /netbsd: callout_softclock() at netbsd:callout_softclock+0x392 Oct 16 12:15:16 vargaz /netbsd: softint_dispatch() at netbsd:softint_dispatch+0xd3 Oct 16 12:15:16 vargaz /netbsd: DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfe80b9fc6ff0 Oct 16 12:15:16 vargaz /netbsd: Xsoftintr() at netbsd:Xsoftintr+0x4f Oct 16 12:15:16 vargaz /netbsd: --- interrupt --- Oct 16 12:15:16 vargaz /netbsd: 0: Oct 16 12:15:16 vargaz /netbsd: cpu0: End traceback... Oct 16 12:15:16 vargaz /netbsd: Oct 16 12:15:16 vargaz /netbsd: dumping to dev 0,1 (offset=199775, size=1023726): Oct 16 12:15:16 vargaz /netbsd: dump succeeded Oct 16 12:15:16 vargaz /netbsd: Oct 16 12:15:16 vargaz /netbsd: Oct 16 12:15:16 vargaz /netbsd: rebooting... Oct 16 12:15:16 vargaz /netbsd: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 200 -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpAW2dZkzxc5.pgp Description: PGP signature
Re: Killing a zombie process?
On 15 Oct 2015, at 00:21, Rhialto wrote: > On Wed 14 Oct 2015 at 09:39:40 +0200, J. Hannken-Illjes wrote: >> Looks like a deadlock, two threads in tstile. >> >> Please take a backtrace (with arguments) of these threads. > > I've got a whole lot more in tstile, and that is even just from running > pkg_comp in the chroot. I didn't try to interrupt anything yet. > > load averages: 0.00, 0.20, 0.44; up 0+02:23:43 > 22:43:52 > 78 processes: 76 sleeping, 2 on CPU > CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle > Memory: 393M Act, 60K Inact, 31M Wired, 31M Exec, 273M File, 3239M Free > Swap: 4096M Total, 4096M Free > > > vargaz:~$ ps alxtp1 > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND > 1000 139174 0 85 0 13208 2528 waitIs ttyp1 0:00.02 -bash > 0 1759 1391 1107 85 0 13304 1576 waitIttyp1 0:00.13 /bin/sh > /usr/pkg/sbin/pkg_comp chroot > 0 865 1759 1107 85 0 13304 1140 waitIttyp1 0:00.01 /bin/sh > /pkg_comp/tmp/pkg_comp-sOjsoA.sh > 0 874 865 13547 82 0 11088 1412 pause Ittyp1 0:00.01 /bin/ksh > 0 267 874 20048 81 0 15360 1720 waitI+ ttyp1 0:00.22 /bin/sh > -e /usr/pkg/sbin/pkg_chk > 0 9782 267 20048 81 0 15360 1448 waitI+ ttyp1 0:00.00 sh -c cd > /usr/pkgsrc/devel/mercurial && /usr/bin/make u > 0 8085 9782 0 117 0 15224 3452 tstile D+ ttyp1 0:00.14 > /usr/bin/make update CLEANDEPENDS > 0 26889 8085 29745 78 0 15360 1424 waitI+ ttyp1 0:00.00 /bin/sh > -c set -e; /usr/bin/env MAKECONF=/etc/mk.conf P > 0 14050 26889 0 117 0 15224 3444 tstile D+ ttyp1 0:00.14 > /usr/bin/make _MAKE OPSYS OS_VERSION LOWER_OPSYS _PKGSR > 0 6325 14050 22699 80 0 15360 1428 waitI+ ttyp1 0:00.00 /bin/sh > -c set -e; pkgpattern=mercurial-3.5.1;\t\t\t\t > 0 13334 6325 0 117 0 15224 3452 tstile D+ ttyp1 0:00.14 > /usr/bin/make .MAKE.LEVEL.ENV CLEANDEPENDS HOST_OSTYPE > 0 2892 13334 29745 78 0 15364 1444 waitI+ ttyp1 0:00.00 /bin/sh > -c set -e;\t\t\t\t\t\t\t\t exec 3<&0;\t\t\t\t\t > 0 13425 2892 29745 78 0 15364 1136 waitI+ ttyp1 0:00.00 /bin/sh > -c set -e;\t\t\t\t\t\t\t\t exec 3<&0;\t\t\t\t\t > 0 17339 13425 0 117 0 15224 3504 tstile D+ ttyp1 0:00.16 > /usr/bin/make .MAKE.LEVEL.ENV CLEANDEPENDS DEPENDS_TARG > 0 11893 17339 23601 80 0 15364 1432 waitI+ ttyp1 0:00.00 /bin/sh > -c set -e; pkgpattern=py27-mercurial\\>=3.5.1;\ > 0 21797 11893 0 117 0 15228 3512 tstile D+ ttyp1 0:00.18 > /usr/bin/make .MAKE.LEVEL.ENV CLEANDEPENDS DEPENDS_TARG > 0 1347 21797 23778 80 0 15364 1456 waitI+ ttyp1 0:00.00 /bin/sh > -c set -e;\t\t\t\t\t if test -n "" && /usr/pkg > 0 23567 1347 0 117 0 15228 4032 tstile D+ ttyp1 0:00.38 > /usr/bin/make .MAKE.LEVEL.ENV CLEANDEPENDS DEPENDS_TARG > 0 3383 23567 29360 78 0 15364 1432 waitI+ ttyp1 0:00.00 /bin/sh > -c (cd /pkg_comp/obj/pkgsrc/devel/py-mercurial/ > 0 21311 3383 28277 79 0 81652 11580 waitI+ ttyp1 0:00.14 > /usr/pkg/bin/python2.7 setup.py build > 0 24114 21311 28277 79 0 15364 1424 waitI+ ttyp1 0:00.01 /bin/sh > /pkg_comp/obj/pkgsrc/devel/py-mercurial/default > 0 3590 24114 28277 79 0 15364 1472 waitI+ ttyp1 0:00.00 /bin/sh > /usr/pkgsrc/mk/tools/msgfmt.sh > 0 7060 3590 28277 117 0 4244 188 tstile D+ ttyp1 0:00.00 /bin/cat > 0 18497 3590 28277 79 0 10880 1064 pipe_wr I+ ttyp1 0:00.00 /bin/cat > i18n/el.po > 0 23883 3590 0 117 0 6580 236 netio D+ ttyp1 0:00.00 > /usr/bin/msgfmt -v -o mercurial/locale/el/LC_MESSAGES/h > 0 27257 3590 28277 117 0 4244 188 tstile D+ ttyp1 0:00.00 /bin/cat > 0 29472 3590 28277 79 0 14244 2344 pipe_wr I+ ttyp1 0:00.01 > /usr/bin/awk -f /usr/bin/awk > > (I've re-arranged the order to get parents before children) > > Here are backtraces of the processes in tstile (and the shell that > spawned the 4 leaf children). I have kept the dump so I can examine it > further. > > Unfortunately, crash(8) didn't give me arguments, nor did ddb when I > tried that (I used the GENERIC kernel, what options do I need to get the > arguments?) > > Script started on Wed Oct 14 23:41:43 2015 > vargaz:~/crash$ crash -M netbsd.3.core -N netbsd.test > Crash version 7.0, image version 7.99.21. > WARNING: versions differ, you may not be able to examine this image. > System panicked: dump forced via kernel debugger > Backtrace from time of crash is available. > > > crash> bt/t 0t3590 > trace: pid 3590 lid 1 at 0xfe8040758d00 > sleepq_block() at sleepq_block+0xa2 > cv_wait_sig() at cv_wait_sig+0xfe > do_sys_wait() at do_sys_wait+0x22c > sys___wait450() at sys___wait450+0x3a > syscall() at syscall+0x9c > --- syscall (number 449) --- > 7f7ff683c1ea: > > > crash> bt/t 0t7060 > trace: pid 7060 lid 1 at 0xfe804076c770 > sleepq_block() at sleepq_block+0xa2 > t
Re: Killing a zombie process?
On 16 Oct 2015, at 13:44, Rhialto wrote: > On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote: >> On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote: >>> Do you really need that mounted twice like that, and if not, can you try >>> with one of them missing and see if the problem remains ? >> >> Good idea, I'll try that later! > > "Interesting" results: it built packages overnight (from around 22:30 to > 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted. With panic? -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Killing a zombie process?
On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote: > On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote: > > Do you really need that mounted twice like that, and if not, can you try > > with one of them missing and see if the problem remains ? > > Good idea, I'll try that later! "Interesting" results: it built packages overnight (from around 22:30 to 12:13, so for nearly 14 hours), then, when I didn't look, it rebooted. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpjZl4aS0WfY.pgp Description: PGP signature
Heads up - crash/panic on -current when unloading mqueue module
Recently I added a module dependency, so compat_netbsd32 will autoload mqueue module. Well, it seems that something during a pkgsrc build-from-source will trigger this. A little bit later, when the module auto-unload thread tries to unload mqueue, I got a panic, with backtrace pool_destroy + 0xb1 pool_cache_destroy + 0xd mqueue_sysfini + 0x44 mqueue_modcmd + 0x28 module_do_unload + 0x74 module_thread + 0xf8 This is on a amd64 system, with kernel and modules built from sources dated 2015-10-13 at 11:29:08 UTC. I'm going to dig a little bit deeper soon, to see what is broken. In the meantime, if anyone uses a run-time loaded mqueue module, rather than one built-in to your kernel, I recommend that you manually load the module at start-up rather than letting it auto-{,un}load. (GENERIC kernels include all relevant modules as built-in, so this will not apply.) +--+--+-+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--+-+