Linux

Name service request caching with nscd

Sometimes it is still easiest (especially when there is only a command line terminal available) to directly edit files like /etc/passwd, /etc/hosts etc. with a plain text editor. When I today just wanted to change the login shell of a user on an Oracle Enterprise Linux installation, I simply changed /bin/csh to /bin/bash for the corresponding entry in /etc/passwd. However, the surprise was that the new entry was not considered when re-logging in. This is where nscd comes into play. From the man page:

NSCD(8)                    Linux Programmer's Manual                   NSCD(8)

NAME
       /usr/sbin/nscd - name service cache daemon

DESCRIPTION
       Nscd  is a daemon that provides a cache for the most common name service requests.  ...

Among those most common name service requests are lookups into the /etc/hosts, /etc/group and /etc/hosts files. Actually the nscd daemon also watches the respective files for changes, but it might take several minutes until it picks up the modified files.To clear the nscd cache immediately, simply call nscd with the -i switch and the name of the lookup database which needs to be reloaded:

$ /usr/sbin/nscd -i passwd

By the way, stopping and re-starting the nscd daemon through /etc/init.d/nscd is not enough – the daemon still remembers its cached entries afterwards.

New Linux installation

A couple of weeks ago, I installed kubuntu 8.10 as my primary operating system. My debian installation was quite outdated, because I did not change much in the last – well – two years or so. I really needed a stable system, but now it was time to update to a recent distribution. Even though I have a 64 bit CPU, I decided to install the 32 bit version of Kubuntu. The main reason was that in the past I often had issues with software which was not yet available for 64 bit Linux. The plan is to use a stable 32 bit system for daily usage, and create either chroot environments for other usage (like a debian unstable environment) or even use virtual machines when necessary. Installation of Kubuntu was quite straight forward, and I will talk about some of the less straight forward things in some upcoming posts.

First impression of upstart

Yesterday, I had a closer look at upstart, a replacement for the sysv init daemon. My goal is to speed up the boot process of my Debian desktop installations, and the two systems which could help with this are upstart and initng. There are packages for upstart in Debian experimental, and installing is quite simple, but besides the upstart package itself it is almost a must to also install the package upstart-compat-sysv, otherwise commands like reboot and shutdown are not available anymore. Also, this package provides a default configuration for the upstart jobs which simply emulates the sysv-init based rc mechanism. Upstart uses the notation of jobs to define the services to start. Unfortunately the sysv-init emulation simply defines jobs like rc1, rc2 and so on, i.e. one job per run level; then, the old sysv-init scripts are still used to launch the services one after the other. The result is that the boot process still took 31 seconds, exactly the same time it took with the sysv-init system. I then started to write some jobs to launch services like apache2 and sshd independently from the rc scripts, using upstart event definitions. Creating the scripts themselves is quite easy, but I did not manage to stop the services again through upstart’s initctl command line interface: it seems that, since the processes fork, upstart assumes that they are stoped again after they have been launched. Investigation is ongoing …

Debian work done lately

Last week, I fixed my first RC bug: it was caused by the removal of libapr0, which rendered my subcommander package uninstallable. Since there was also a new upstream version available, I combined this with the upload. Since some weeks, my debian package overview looks messed up. All entries appear twice, and most of my (not yet so many 😉 ) packages are missing. It seems that this happened after the upload of libtest-unit-perl, the first package I co-maintain within a group. So, I spent some time today setting up a local qa.debian.org environment and tracking down what goes wrong. I have created a bug report with an attached patch which should fix the issue; I hope that it will be committed sometime soon so that the complete package overview is working again.