Re: Jails that won't die...
From: Brian Fundakowski Feldman (green_at_freebsd.org)
Date: 06/30/05
- Previous message: lars: "How is the patchlevel set?"
- In reply to: Eirik Øverby: "Re: Jails that won't die..."
- Next in thread: Eirik Øverby: "Re: Jails that won't die..."
- Reply: Eirik Øverby: "Re: Jails that won't die..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 30 Jun 2005 16:56:29 -0400 To: Eirik Qverby?= <eirik@unicore.no>
On Thu, Jun 30, 2005 at 03:53:56PM +0200, Eirik Øverby wrote:
>
> On 29. jun. 2005, at 20.58, Brian Fundakowski Feldman wrote:
>
> >On Wed, Jun 29, 2005 at 03:28:09PM +0200, Eirik Øverby wrote:
> >
> >>
> >>On 28. jun. 2005, at 16.58, Brian Fundakowski Feldman wrote:
> >>
> >>
> >>>On Tue, Jun 28, 2005 at 10:37:29AM +0200, Eirik Øverby wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>I have, since upgrading to 5.x and updating my management tools,
> >>>>seen
> >>>>a number of problems relating to stopping jails.
> >>>>
> >>>>I'm maintaining several hosts with a number of full-featured jails
> >>>>(i.e. full virtual FreeBSD installations in each jail), and in
> >>>>general this works fine. However, whenever I stop a jail using
> >>>>'jexec
> >>>><id> kill -SIGNAL -1' or 'jexec <id> /bin/sh /etc/rc.shutdown' (in
> >>>>various combinations), jails have a tendency to stick around for
> >>>>minutes or hours - according to 'jls'. Often I see an entry in
> >>>>'netstat -a' indicating that there is one or more sockets in
> >>>>FIN_WAIT
> >>>>state, preventing the jail from coming down. Taking the virtual
> >>>>network interface (alias) down does not help. All I can do at this
> >>>>point is wait.
> >>>>
> >>>>I normally use 'jls' to determine whether or not a jail can be
> >>>>restarted (i.e. it's not running), but this is pretty useless in
> >>>>such
> >>>>cases. And right now I have a case where 'netstat -a' shows me
> >>>>nothing pertaining to the jail, though it has no processes
> >>>>running. I
> >>>>have therefore force-started the jail again, which seems to work
> >>>>nicely, but now 'jls' gives me two entries for this jail, with
> >>>>different JIDs.
> >>>>
> >>>>What am I doing wrong here?
> >>>>
> >>>>
> >>>
> >>>You could just use ps to check for jailed processes and check their
> >>>respective jails using the procfs status entry (at least according
> >>>to the ps manpage...)
> >>>
> >>
> >>My jailctl script can do both - list by jls and list by processes in
> >>the jail. There are NO processes running in the jail.
> >>
> >
> >So it's obviously not running, and you can mark its state as such.
>
> ...which is what I do on FreeBSD 4.x, but on 5.x the 'jls' command
> still claims the jail is running. I think this is unbelieveably
> dirty. Also, using /proc to determine if a jail is still running is a
> bad idea, as mounting /proc is depreceated.
The deprecation is due to security concerns, not bit-rot. You can
just mount it with root-readable-only permissions. The jls for
current isn't incorrect, you're just expecting a different criteria to
mean "alive" than it is using. It would take increased kernel
complexity to do what you want if you're not going to do it in
userland.
Anyway, why aren't you just using a /var/run file in the "real" system
to tell whether the jail is running or not? It's the corollary to
pid files versus doing "killall"... Just seems like something really
trivial to implement as you like it in the userland.
-- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
- Previous message: lars: "How is the patchlevel set?"
- In reply to: Eirik Øverby: "Re: Jails that won't die..."
- Next in thread: Eirik Øverby: "Re: Jails that won't die..."
- Reply: Eirik Øverby: "Re: Jails that won't die..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
