Date: Sun, 1 Jul 2001 15:59:43 +1000 (EST) From: Tony Maher <tonym@biolateral.com.au> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/28566: Mount_null loopbacks can hang startx temporarily Message-ID: <200107010559.f615xhx02033@dt.home>
next in thread | raw e-mail | index | archive | help
>Number: 28566 >Category: kern >Synopsis: Mount_null loopbacks can hang startx temporarily >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 30 23:10:01 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Tony Maher >Release: FreeBSD 4.3-STABLE i386 >Organization: Biolateral >Environment: System: FreeBSD dt.home 4.3-STABLE FreeBSD 4.3-STABLE #0: Fri Jun 29 11:03:46 EST 2001 root@dt.home:/usr/obj/usr/src/sys/DT i386 >Description: Seeing merges to fix null_fs (and yes I note the warning is still in mount_null.8), I decided to ty it out and remove a couple of symlinks and try to loopback with mount_null. e.g. mount_null /space/usr/src /usr/src mount_null /var/obj /usr/obj I successfully did a make world cycle and fsck'ed the disks and all was ok. So decide to remove all symlinks and use mount_null loopbacks instead. My /etc/fstab looks like this: /space/home/staff /home/staff null rw 0 0 /space/db/mysql /db/mysql null rw 0 0 /space/db/pgsql /db/pgsql null rw 0 0 /space/usr/doc /usr/doc null rw 0 0 /space/usr/ports /usr/ports null rw 0 0 /space/usr/src /usr/src null rw 0 0 /var/obj /usr/obj null rw 0 0 Everything appeared to start ok and can login fine. When trying to use startx it hung (something to do with xauth) but eventually works after a minute or so. Truss shows a couple of differences around here: (sorry this is extra wide output here to show the diffs) Hanging version Normal version pipe() = 3 (0x3) pipe() = 3 (0x3) fork() = 484 (0x1e4 | fork() = 402 (0x192 close(4) = 0 (0x0) close(4) = 0 (0x0) fork() = 485 (0x1e5 | fork() = 403 (0x193 > SIGNAL 20 > SIGNAL 20 close(3) = 0 (0x0) close(3) = 0 (0x0) close(-1) ERR#9 'Bad f close(-1) ERR#9 'Bad f getpgrp() = 469 (0x1d5 | getpgrp() = 387 (0x183 xauth: (argv):1: bad display name "dt.home:0" in "list" comm | wait4(0xffffffff,0xbfbff8e0,0x2,0x0) = 403 (0x193 SIGNAL 20 | wait4(0xffffffff,0xbfbff8e0,0x2,0x0) = 402 (0x192 wait4(0xffffffff,0xbfbff8e0,0x2,0x0) = 485 (0x1e5 | fork() = 404 (0x194 wait4(0xffffffff,0xbfbff8e0,0x2,0x0) = 484 (0x1e4 | getpgrp() = 387 (0x183 xauth: (argv):1: bad display name "dt.home:0" in "add" comma < fork() = 486 (0x1e6 < SIGNAL 20 SIGNAL 20 getpgrp() = 469 (0x1d5 | wait4(0xffffffff,0xbfbff850,0x2,0x0) = 404 (0x194 wait4(0xffffffff,0xbfbff850,0x2,0x0) = 486 (0x1e6 < read(0xa,0x80bb600,0x3ff) = 107 (0x6b) read(0xa,0x80bb600,0x3ff) = 107 (0x6b) >How-To-Repeat: Use mount_null for home directories and try to startx (see under Fix: the home directories have to be the first mount_null entry) >Fix: The strange thing was if I added noauto option to /space/home/staff entry in fstab and the manuaully mounted it, then startx worked perfectly. By modifying /etc/rc and doing the explicit mount after "mount -a" it worked. Decided it was probably to do with it being the first mount_null entry. So swapping first and second entries so that /space/home/staff entry became the second entry it worked perfectly. Deciding to put in a dummy mount_null entry that is not actually used for anything rather than risk strange behaviour on another working mount point (and keeping /space/home/staff as second entry) e.g. /space/hack /usr/hack null rw 0 0 /space/home/staff /home/staff null rw 0 0 /space/db/mysql /db/mysql null rw 0 0 and the hanging problem *was* present again! On a whim (well actually to match format of the original second entry /space/db/mysql that I had succesfully swapped and tested previously) I changed it to /space/hack/hack /usr/hack null rw 0 0 /space/home/staff /home/staff null rw 0 0 /space/db/mysql /db/mysql null rw 0 0 and the hanging problem was *not* there! Everything seems to be ok with this hack but I have not done any heavy duty work wiht it. This is on my laptop (Dell Inspiron 3500) which I mention as it had weird behaviour with mount_smbfs (and this was reported to bp in private emails last year) >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107010559.f615xhx02033>