From owner-freebsd-hackers Sun Nov 2 01:42:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA12502 for hackers-outgoing; Sun, 2 Nov 1997 01:42:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA12494 for ; Sun, 2 Nov 1997 01:42:39 -0800 (PST) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.7/8.8.7) id BAA28878; Sun, 2 Nov 1997 01:42:38 -0800 (PST) Message-ID: <19971102014238.14394@hydrogen.nike.efn.org> Date: Sun, 2 Nov 1997 01:42:38 -0800 From: John-Mark Gurney To: FreeBSD Hackers Subject: portal pid not correct... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well.. I was looking at the diffent fs's supported (and using kld to load 'em)... and noticed something strange... note,ttyp0,/dev,666#df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/wd0a 127151 111657 5322 95% / /dev/wd0s2 170264 163352 6912 96% /msdos procfs 4 4 0 100% /proc hydrogen:/a 1803463 1350919 308267 81% /a hydrogen:/b 1748071 1498998 109228 93% /b kernfs 1 1 0 100% /kern portal:4254 1 1 0 100% /mnt then a search for procid 4254: note,ttyp0,/dev,667#ps lax | grep 4254 note,ttyp0,/dev,668# now a search for a portal process: note,ttyp0,/dev,668#ps lax | grep portal 0 4255 1 0 2 0 416 212 select Is ?? 0:00.01 portal /tmp/ I took a look at the code.. and basicly it doesn't become a daemon before tring to mount the fs... and this is understandable else you can't return a failed mount... now as I see this, there are a couple ways to fix this... a) just become a daemon and then mount, this isn't very attrative as the error doesn't get reported b) do something were it will fork off the child, child will immediately SIGSTOP itself, then parent will mount, and then parent will SIGCONT the process for normal execution, or kill it off if the mount failed. c) insert your idea hear comments? ideas? -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD