Re: Finding the current drive devices

[Michael van Elst]

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 network devices

[Michael van Elst]

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

[D'Arcy J.M. Cain]

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

Heads up - crash/panic on -current when unloading mqueue module

[Paul Goyette]

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  |
+--+--+-+

Re: Killing a zombie process?

[Rhialto]

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

Re: Killing a zombie process?

[Rhialto]

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?

[J. Hannken-Illjes]

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 

Re: Killing a zombie process?

[Rhialto]

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?

[J. Hannken-Illjes]

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

daily CVS update output

[NetBSD source update]

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: