[lxc-users] Question about existing defaults

Thu Apr 17 18:27:14 UTC 2014

On Thu, 2014-04-17 at 07:29 -0400, CDR wrote:
> I followed the instructions and it works, indeed.
> I erased first all lxc rpms and the installed the new ones

> rpm -qa |grep lxc
> lxc-libs-1.0.3-1.fc20.x86_64
> lxc-debuginfo-1.0.3-1.fc20.x86_64
> lxc-1.0.3-1.fc20.x86_64
> libvirt-daemon-driver-lxc-1.1.3.4-4.fc20.x86_64

> However, I hit a problem when starting a container.
> lxc-start -d -n dialer-1
> lxc-start: symbol lookup error: lxc-start: undefined symbol: lxc_caps_init

> This means that the code is left to pull this function from package
> that is not there?

That usually means you've got an old library dangling around or you have
processes with a deleted library locked in memory.  That most often
happens when you've done a manual "./configure ; make ; make install"
and pieces are now installed where you don't want them.  In that case,
ldconfig may have the lxc-libs located in a different path location than
what you've installed.  It could also occur if you have running
containers with an incompatible library.

First thing I would do is inspect /usr/local and look for any lxc
components and get rid of them.

Second thing I would do is reboot to make sure you have no stale
processes holding an old library in common memory.

Then try it again.

This is why I strictly go with the yum/rpm route when working with
managed packages like LXC.

> Any help would be appreciated, or a patch that would not use this
> function. My containers are unbound, only for internal use, so I want
> them to use as much resources as needed.

What rpm is showing is that you have a coherent set of packages that
should not be encountering this problem.  The error indicates the
presence of an unmanaged library in memory on on disk.  You might track
it down using "ldd /usr/bin/lxc-start" and see what that gives you.

> Philip

Regards,
Mike

> On Wed, Apr 16, 2014 at 11:41 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > On Wed, 2014-04-16 at 22:04 -0400, CDR wrote:
> >> I am using Fedora 20 and try to compile the very latest sources,
> >> because they bring new utilities that are very useful.
> >> You would assume, I think, that by using ./configure
> >> --with-distro=fedora, the right defaults would be pulled over. It is
> >> not the case. I need to know how to apply the existing defaults if the
> >> software is already running in the box, so the libraries and utilities
> >> do not get written to a different places. Particularly annoying is the
> >> location of the config files.
> >
> >> In summary, don't we agree that by using the distro name, the software
> >> should either extract or know the right defaults? Unless somebody has
> >> a secret way to extract that information from the RPM offered by the
> >> distribution.
> >
> > Interesting.  I guess this is one I might field, since I'm responsible
> > for the Fedora template (which does NOT imply the Fedora build).  I
> > don't know who the Fedora package manager for the LXC package is and I
> > haven't heard from him or her.
> >
> > I, for one, would NOT expect "./configure --with-distro=fedora" to pull
> > the correct results.  That's from experience, although I've never used
> > it myself.  It's just something none of us have thought to maintain and
> > I have never looked into it.  I didn't even know the option was there in
> > configure.
> >
> > The Fedora Project itself does not even use the default lxc.spec rpm
> > spec file from the project but chooses their own .spec file and
> > packaging.  Largely, the defaults are similar...
> >
> > I had been using an explicit build based on our .spec file to create tar
> > files and build rpm files using "rpmbuild -ta" but another contributor,
> > Dwight (Oracle), pointed out to me that I could just do a "make rpm" in
> > a source directory and it would to the correct things to create a Fedora
> > rpm.  I've been very successful doing that and now that's all I do.  It
> > does the right things.  It uses slightly different packaging from the
> > "official" Fedora packages but one that's compatible with the Fedora
> > packaging.
> >
> > If you are manually running "./configure" and "make" on our sources on
> > Fedora, my first advice would be DON'T.  You're doing things the hard
> > way.  I don't even do that with any stock rpm packages I'm working on.
> > Work through the yum/rpm system.  Run "make rpm" and install the rpms
> > using "yum localinstall".  That will prevent you from ending up with
> > conflicting binaries in differing locations.
> >
> > In this case, it's actually easier to do the right thing than it is to
> > do the manual thing the hard way.  You're trying too hard.
> >
> >> Philip
> >
> > Regards,
> > Mike
> > --
> > Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
> >    /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
> >    NIC whois: MHW9          | An optimist believes we live in the best of all
> >  PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
> >
> >
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20140417/e53acbe2/attachment.sig>