Re: [vserver] cannot find vserver-setup

On Wednesday, September 28, 2011, Herbert Poetzl wrote:
> On Wed, Sep 28, 2011 at 11:56:09AM -0400, Chuck wrote:
> > On Wednesday, September 28, 2011, Herbert Poetzl wrote:
> >> On Wed, Sep 28, 2011 at 11:17:25AM -0400, Chuck wrote:
> >>> On Wednesday, September 28, 2011, Herbert Poetzl wrote:
> >>>> On Wed, Sep 28, 2011 at 06:26:08AM -0400, Chuck wrote:
>
> >>>>> i have a running vserver that works perfectly but today i
> >>>>> cannot enter it. i can enter others but not this one meaning i
> >>>>> also cannot shut it down manually. i get the following error:
>
> >>>>> enterprise vservers # vserver cacti enter Can not find a
> >>>>> vserver-setup at '/etc/vservers/cacti/'.
>
> >>>> depending on the kernel, check for stray barrier at
> >>>> unexpected places and/or run the enter with --debug
> >>>> and provide us with the output
>
> >>> no barrier anywhere that i can find.. here is the debug output.
>
> >> specifically check '/', '/etc', '/etc/vserver' and the
> >> guest's config/data dirs ...
>
> >>> enterprise etc # vserver --debug cacti enter
>
> >> [zapped]
>
> >>> + test -d /etc/vservers/cacti
> >>> + _setVserverName
> >>> ++ basename /etc/vservers/cacti
>
> >> here the /etc/vservers/cacti dir exists and is
> >> visible to util-vserver ...
>
> >>> + VSERVER_NAME=cacti
>
> >> [zapped]
>
> >>> + exec /usr/sbin/vspace --mount --fs --enter /etc/vservers/cacti --
/usr/sbin/vserver
> > ---- nonamespace --debug cacti enter
>
> >> [zapped]
>
> >>> + test -d /etc/vservers/cacti
> >>> + echo 'Can not find a vserver-setup at '\''/etc/vservers/cacti/'\''.
>
> >> here, after entering the namespaces, it doesn't ...
>
> >> is /etc/vservers or /etc/vservers/cacti some kind of
> >> mount or filesystem or volume which might disappear
> >> when inside a namespace?
>
>
> > all hosts share /etc/vservers in an nfs share from one machine
> > to make life easy for updating. i unmounted the share on that
> > machine and it still gives the error. nfs marks the dir as
> > chmod 777.
>
> > the way our system is now set up is all vservers live on the
> > san and all hosts can see all vservers. likewise all hosts
> > can see the listing of all vservers from /etc/vservers . this
> > makes life easy in moving vservers from one machine to another.
> > simply stop on one and start on the other one, clear the router
> > arp cache and its a go.
>
> > cacti is the only one we are having trouble with.
>
> okay, what does the following give:
>
> /usr/sbin/vspace --mount --fs --enter /etc/vservers/cacti -- /bin/bash
>
> then from within the shell:
>
> ls -la /etc/vservers/cacti
>
> (don't forget to exit the namespace bash)
>
> >> also, what kernel/patch/util-vserver version are we
> >> talking about?
>
> > vserver-sources-2.3.0.36.32 also known as linux-2.6.35-vserver-2.3.0.36.32
>
> > util-vserver-0.30.216_pre2955
>
> hmm, I'd update that to at least 2.6.35.12-vs2.3.0.36.33
> but better to 2.6.38.8-vs2.3.0.37-rc17 and recent util-vserver
>

i had a look at the cacti vserver root dir today and i think i may have seen the problem.
somehow, the cacti config info from /etc/vservers was copied into the vserver's root dir.
i guess the utils got confused and saw configs sitting inside the vserver and tried to use
them which would explain losing the path.. anyway i removed all the extraneous things from
the root of the guest itself, so we will see how things go. i expect it will go fine. this
guest has been running perfectly since 2008 so i see no reason for it to begin acting up
without human error involved.

> best,
> Herbert
>
> >> thanks in advance,
> >> Herbert
>
> >>> here is the 'root' content of the /etc/vservers/cacti directory
>
> >>> drwxr-xr-x 7 root root 408 2010-07-31 10:28 .
> >>> drwxrwxrwx 35 root root 872 2011-09-28 05:11 ..
> >>> drwxr-xr-x 3 root root 72 2008-11-19 11:49 apps
> >>> -rw-r--r-- 1 root root 26 2009-01-27 15:22 bcapabilities
> >>> lrwxrwxrwx 1 root root 39 2011-09-22 17:41 cache ->
> >>> /etc/vservers/.defaults/cachebase/cacti
> >>> -rw-r--r-- 1 root root 10 2009-01-27 15:21 ccapabilities
> >>> -rw-r--r-- 1 root root 5 2008-11-19 11:49 context
> >>> drwxr-xr-x 2 root root 48 2008-11-19 11:49 cpuset
> >>> -rw-r--r-- 1 root root 41 2008-11-19 12:22 flags
> >>> -rw-r--r-- 1 root root 251 2008-11-19 12:23 fstab
> >>> drwxr-xr-x 4 root root 96 2008-11-19 22:24 interfaces
> >>> -rw-r--r-- 1 root root 6 2008-11-19 11:49 name
> >>> lrwxrwxrwx 1 root root 23 2011-09-22 17:41 run -> /var/run/vservers/cacti
> >>> drwxr-xr-x 2 root root 112 2008-11-19 12:22 scripts
> >>> drwxr-xr-x 2 root root 72 2008-11-19 11:49 uts
> >>> lrwxrwxrwx 1 root root 38 2011-09-22 17:41 vdir ->
> >>> /etc/vservers/.defaults/vdirbase/cacti
>
> >>>>> Possible solutions: * fix the spelling of the 'cacti' vserver
> >>>>> name * read 'vserver cacti build --help' about ways to create
> >>>>> a new vserver * see 'vserver --help' for the syntax of this
> >>>>> command
>
> >>>>> i compared the contents of that dir with others and it looks
> >>>>> the same.
>
> >>>> well, an ls -la /etc/vservers/cacti/ might helpt
> >>>> here as well ...
>
> >>>>> any clues where to look?
>
> >>>> see above, best,
> >>>> Herbert
>
> >>>>> there was a host crash that was hardware related but it is
> >>>>> back up and everything works. i had to rename some dirs in a
> >>>>> vserver and copy their contents into the new dir because i kept
> >>>>> getting an apache message 'not a valid directory' however that
> >>>>> is fixed. i thought this problem may be similar but renaming
> >>>>> and copying contents did not help.
>
> >>>>> --
>
> >>>>> Chuck
>
>
>
> >>> --
>
> >>> Chuck
>
>
>
> > --
>
> > Chuck
>

-- 
Chuck