Re: kern/89528: [jail] impossible to kill a jail

[Juergen Unger]

Hi !

I had this problem on my machines many times now.

One additional thing I found:

on my machines all jails have their own (virtual) disks mounted
to the root-fs of the jail.
In the case a zombie jail is left after stopping a jail 
the entry in the jls output is still visible _and_ 
it is not possible to umount the virtual disk of the jail
anymore.  

This is very independant of the version, it occured from my
first productive 5.x versions up to 6.2 RELEASE where i got
the problem again today.

Maybe it leads us further if we try to investigate this.

bye,
  Juergen

-- 
ENOSIG
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mergemaster improvement (auto-update for not modified files)

[Juergen Unger]

On Tue, May 03, 2005 at 11:15:51AM -0700, Julian Elischer wrote:
> c0ldbyte wrote:
[...]
> >But with all due respect, This just seems like another case of a
> >"Bike Shed" incident.
> not at all.
> I've wanted this for a long time..
> files that I have not touched are at default state and I wnat them to move 
> to teh new default state. Files I have touched, I want to look at by hand.

so do I.  And to go a step further: why do we at all have to run
this things in single-user mode ?
Not that I am not aware of the technical reasons for it
BUT: why don't we run both the installworld and the mergemaster
jobs in a manner where they only _preparing_ the installation of
the update ? ... maybe creating a jobfile which could be
run automatically during reboot to make the update instantaneous
happen without a long downtime to do it all manually in
single-user mode over a slow serial console ?

bye,
  Juergen

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

jails and output of df/mount [PATCH]

[Juergen Unger]

Hi !

within a jail there are at this time two possibilities
of operation for the syscall getfsstat (which is used e.g.
for the commands 'df' and 'mount'):

security.jail.getfsstatroot_only = 0:
getfsstat return all filesystems mounted anywhere at the machine

security.jail.getfsstatroot_only = 1:
getfsstat returns the filesystem where the jail-root is in
and nothing more (mountpoints within the jails fs-tree are not
returned)

IMHO is this 2nd one not what is really needed:  If we
have additional filesystems mounted within the jails tree
they should be visible too so that they are shown with
a simple 'df' or 'mount'.

I made a small patch for this which is available at

and should work against CURRENT and RELENG_5_4

Any comments ?  I am not sure if there is locking needed
(mtx_lock, mtx_unlock) around this new piece of code, at this
time ot works for me without locking...
Any other opinions ?  

bye,
  Juergen


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: jails and output of df/mount [PATCH]

[Juergen Unger]

Hi Jeremie !

On Tue, May 17, 2005 at 11:43:24PM +0200, Jeremie Le Hen wrote:
[...]
> This works fine on a recent RELENG_5 UP kernel.  Given that this
> exposes some host configuration inside jail, it might be worth
> adding a sysctl to disable this.  However, I'm not really sure
> this kind of information could really be an attack vector or ramp.

I don't share your opinion that this exposes information not
allready known to the processes withing the jail.  For example:

with this patch I get on an sample jail here the following
output:

> jail# df -h
> Filesystem  SizeUsed   Avail Capacity  Mounted on
> /dev/md3c   4.8G148M4.3G 3%/data1/jail/003
> 195.49.136.4:/po989M275M635M30%/data1/jail/003/usr/ports
> 195.49.136.4:/di989M189M721M21%/data1/jail/003/distfiles
> 195.49.136.4:/pa989M 83M828M 9%/data1/jail/003/packages
> /dev/md2001c 19G4.0K 18G 0%
> /data1/jail/003/var/spool/news
> devfs   1.0K1.0K  0B   100%/data1/jail/003/dev
> fdescfs 1.0K1.0K  0B   100%/data1/jail/003/dev/fd
> procfs  4.0K4.0K  0B   100%/data1/jail/003/proc
> jail# 

the processes within the jail can get the same information without
the patch if they call df for each mounted fs seperately:

> jail# df -h /
> FilesystemSizeUsed   Avail Capacity  Mounted on
> /dev/md3c 4.8G148M4.3G 3%/data1/jail/003
> jail# df -h /usr/ports
> Filesystem  SizeUsed   Avail Capacity  Mounted on
> 195.49.136.4:/po989M275M635M30%/data1/jail/003/usr/ports
> jail# df -h /distfiles
> Filesystem  SizeUsed   Avail Capacity  Mounted on
> 195.49.136.4:/di989M189M721M21%/data1/jail/003/distfiles
.
[...and.so.on...]
.

that in the output the '/data1/jail/003/' path component ist shown
is another point to fix (I will make another patch for it), but
this behaviour is not changed from before.  Better it would
be only output the path at it is known to the jailed processes.

> There seems to be one small bug in your patch : once applied, we
> don't see informations about / any longer inside jails.

hmm, I think I know what you mean.  I am very sure this happens only
if the jail do not have an own filesystem (so the jails root is
not the root of a filesystem).  Should be easy to fix.  I will
make an improved patch until tomorrow.

bye,
  Juergen


-- 
ENOSIG
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: jails and output of df/mount [PATCH]

[Juergen Unger]

On Tue, May 17, 2005 at 11:43:24PM +0200, Jeremie Le Hen wrote:
[...]
> There seems to be one small bug in your patch : once applied, we
> don't see informations about / any longer inside jails.

please try the new one at


bye,
  Juergen

-- 
ENOSIG
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: snapshots and innds

[Juergen Unger]

Hi !

I don't know if its may or may not be from the same reason:
On an 5.4-p1 I started using snapshots on loopback mouted
files with mdconfig.  First I seems to be all ok but then
more first one, then more and more processes get stuck in some
(for me) unknown state and in the end even the start of the
login shell for the serial console hang.  Since I did not
know how to look more into detail with this stuck processes
the only way was to power-cycle.
What can I do to track down this problem when I am able
to reproduce it on the my testmachine (which is identical
except memory to the system where it happend) ?

any help welcome,

  Juergen

On Sun, May 22, 2005 at 10:17:30PM -0700, Kirk McKusick wrote:
> Excellent detective work on your part. The invarient that is being
> broken here is that you are never supposed to hold a vnode locked
> when you call vn_start_write. The call to vn_start_write should
> be done in vm_object_sync before acquiring the vnode lock rather
> than later in vnode_pager_putpages. Of course, moving the
> vn_start_write out of vnode_pager_putpages means that we have to
> track down every other caller of vnode_pager_putpages to make sure
> that they have also done the vn_start_write call as well.
>
> Jeff Robertson has come up with a much cleaner way of dealing with
> the suspension code that I believe he is using in the -current tree.
> It puts a hook in the ufs_lock code that tracks the number of locks
> held in each filesystem. To do a suspend, it blocks all new lock
> requests on that filesystem by any thread that does not already
> hold a lock and waits for all the existing locks to be released.
> This obviates the need for the vn_start_write calls sprinkled all
> through the system. I have copied Jeff on this email so that he
> can comment further on this issue as he is much more up to speed
> on it at the moment than I am.
>
>   Kirk McKusick
>
> =-=-=-=-=-=-= 
> >
> From: [EMAIL PROTECTED] (Steve Watt)
> Date: Sun, 22 May 2005 14:02:39 -0700
> In-Reply-To: [EMAIL PROTECTED] (Steve Watt)
>"snapshots and innds" (Dec 18, 17:39)
> To: freebsd-hackers@freebsd.org
> Subject: Re: snapshots and innds
> Cc: [EMAIL PROTECTED]
> X-Archived: [EMAIL PROTECTED]
> X-ASK-Info: Whitelist match [from [EMAIL PROTECTED] (2005/05/22 14:03:00)
>
> [ OK, there's a lot of text in here, but I have definitively found a
>   deadlock between ffs_mksnap and msync(). ]

--
ENOSIG
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"