I spent some time today looking at systemd (44) under Fedora (17). When stopping an LXC container using lxc-stop, I would always encounter this problem:

# lxc-stop -n node0
lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/node0

This prevents one from starting a new container with the same name:

# lxc-start -n node0 
lxc-start: Device or resource busy - failed to remove previous cgroup '/sys/fs/cgroup/systemd/node0'
lxc-start: failed to spawn 'node0'
lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/node0'

You can correct the problem manually by removing all the child cgroups underneath /sys/fs/cgroup/systemd/<container>, like this:

It took me an unreasonably long time to boot an LXC container with working console access. For the record:

When you boot an LXC container, the console appears to be attached to a pts device. For example, when booting with the console attached to your current terminal:

# lxc-start -n node0
...
node0 login: root
Last login: Mon Jan 28 16:35:19 on tty1
[root@node0 ~]# tty
/dev/console
[root@node0 ~]# ls -l /dev/console
crw------- 1 root tty 136, 12 Jan 28 16:36 /dev/console

This is also true when you attach to a container using lxc-console:

I was intrigued by this post on socket activated containers with systemd. The basic premise is:

• systemd opens a socket on the host and listens for connections.
• When a client connections, systemd spawns a new container.
• The host systemd passes the connected socket to the container systemd.
• Services in the container receive these sockets from the container systemd.

This is a very neat idea, since it delegates all the socket listening to the host and only spins up container and service resources when necessary.

This is a followup to an earlier post about Arch Linux.

I’ve since spent a little more time working with Arch, and these are the things I like:

• The base system is very small and has a very short boot time. I replaced Ubuntu on my old Eee PC with Arch and suddenly the boot time is reasonable (< 10 seconds to a text prompt, < 30 seconds to a full GUI login).

I’ve been playing around with the LXC support in libvirt recently, and I’m trying to use a model where each LXC instance is backed by a dedicated LVM volume. This means that the process of starting an instance is:

• mount the instance root filesystem if necessary
• start the instance

It’s annoying to have to do this by hand. I could simply add all the LXC filesystems to /etc/fstab, but this would mean and extra step when creating and deleting each instance.

If you are starting virtual machines via libvirt, and you have attached them to the default network, there is a very simple method you can use to determine the address assigned to your running instance:

• Libvirt runs dnsmasq for the default network, and saves leases in a local file (/var/lib/libvirt/dnsmasq/default.leases under RHEL).
• You can get the MAC address assigned to a virtual machine by querying the domain XML description.

Putting this together gets us something along the lines of:

I decided to take a look at Arch Linux this evening. It’s an interesting idea, but has a long way to go:

• The installer configured the wrong root= command line into my syslinux configuration, resulting in a system that wouldn’t boot.

  Update: As far as I can tell, the syslinux-install_update command doesn’t actually make any attempt to configure syslinux.cfg at all.

• I tried to install libvirt and lxc, but there are unresolved library dependencies…the virsh command apparently requires libX11.so.6, but the package is missing the appropriate dependencies to pull in the necessary packages automatically.

I’m been writing a provisioning tool for OpenStack recently, and I’ve put together a demo configuration that installs a simple cluster consisting of three backend nodes and a front-end http proxy. I needed a way for the backend servers to discover the ip address of the frontend server. Since in my target environment everything would be on the same layer-2 network segment, service discovery with multicast DNS (mDNS) seemed like the way to go.

I needed to replace the native OpenJDK based Java VM with the Oracle Java distribution on one of our CentOS servers. In order to do it cleanly I wanted to set up the alternatives system to handle it, but it took a while to figure out the exact syntax.

For the record (and because I will probably forget):

alternatives --install /usr/bin/java java /usr/java/latest/bin/java 2000 \
  --slave /usr/bin/keytool keytool /usr/java/latest/bin/keytool \
  --slave /usr/bin/rmiregistry rmiregistry /usr/java/latest/bin/rmiregistry

I recently embarked upon a quest to categorize a year’s worth of trouble tickets (around 15000 documents total). We wanted to see what sort of things are generating the most work for our helpdesk staff so that we can identify areas in which improvements would have the biggest impact. One of my colleagues took a first pass at the data by manually categorizing the tickets based on their subject. This resulted in some useful data, but in the end just over 40% of the tickets are still uncategorized.