4.0 Unable to get PID: CT won't start
- Thread starter NerdUno
- Start date
Correct. Using the centos 6 template. The Ubuntu 14 one works fine so this appears to be a CentOS problem. We add several hundred packages from the CentOS repo to bring our servers up to what's needed for our PBX platforms. Thought maybe it was the kernel quirks, but eliminating the kernel issues did not fix the problem.
The easy way would be just to load our script and run it. You can save some time by editing the script once it's untarred and adding an exit command at about line 194. This will let you run through all of the yum commands and exit just before Asterisk, etc. are built. Then reboot and the error will appear.
yum -y install net-tools nano wget tar
wget http://incrediblepbx.com/incrediblepbx13-12.2-centos.tar.gz
tar zxvf incrediblepbx*
./IncrediblePBX*
yum -y install net-tools nano wget tar
wget http://incrediblepbx.com/incrediblepbx13-12.2-centos.tar.gz
tar zxvf incrediblepbx*
./IncrediblePBX*
It's necessarily generic because we support a half dozen different RHEL flavors and about the same number of RHEL versions.
you can easily detect the running platform with a script and then you can act accordingly.
one of the benefits of a container is a lean installation. your script seems to install almost everything (still installing in the background...), so in this case I see no benefit and would choose a VM for this - why do you want to run this as container?
We already have an OpenVZ template, but it's a very old version of everything. What we typically do is install the kitchen sink and then remove packages before creating the container. Installing CentOS packages from the CentOS repo really shouldn't break CentOS, barebones or not.
I'm curious if you believe this is a design flaw in Linux Containers. We never saw this limitation with OpenVZ templates. Frankly, we haven't seen it on any other virtualization platform, and we test almost all of them. I understand running out of RAM or disk space but "too many RPMs" is a new one. Are there package limitations in the Linux Container design that don't exist with other virtualization platforms?