Custom Query (1145 matches)

Reported by broder, 14 years ago.

/etc/schroot/setup/15killprocs in schroot is responsible for making sure that no processes are still running in a chroot when that chroot is torn down.

It does this by looping over the processes still running in the chroot. For each process, it sends a SIGTERM, then immediately checks to see if the process is still running. If not, it then sleeps for 1 second before trying again.

The problem with this approach is that most programs try to handle SIGTERM gracefully, and therefore do not exit out immediately. When geofft instrumented the logout process, it looked like there were about 15 such processes, causing 15 seconds worth of sleep before the logout would continue.

This is the major cause of logout slowness on cluster machines.

When we used LVM snapshots for the login chroots, we had code to use fuser(1) to first SIGTERM and then eventually SIGKILL all processes running within the chroots, but we removed it from snapshot-run when we switched to aufs chroots.

Bringing that code back and adding it before snapshot-run calls schroot -e would eliminate this issue.

Reported by broder, 14 years ago.

When I originally wrote the debathena-metrics code, I used daemon(1) to background the gatherer daemon. Since then, I've learned that daemon is not a particularly well engineered piece of code, and that in spite of being a little bit easier to use, start-stop-daemon is much better put together

It would be a good enhancement to switch debathena-metrics to using start-stop-daemon instead of daemon.

Reported by broder, 14 years ago.

Right now, several of the scripts in /etc/X11/Xsession.d use dpkg-query -W -f '${Status}' PACKAGE to test if a package is installed.

This is necessary because conffiles are not removed when a package is uninstalled (only when it's purged), and Debian Policy dictates that a conffile cause no change when the package is uninstalled (it's only kept so that the configuration can be restored should the package be installed in the future).

However, using dpkg-query requires loading the entire dpkg database into buffer cache, which is a slow process, at least the first time, and happens at a point where there's already lots of disk I/O happening. Looking at bootcharts, it generally takes about 2 seconds. Because that query has to finish before the script can determine whether to do anything, it blocks the login time.

Instead of using dpkg-query, all of those scripts should be changed to use a finer-grained test. For instance, the debathena-larvnet script could check for [ -x /usr/lib/debathena-larvnet/larvnet-wrapper ], which is much less filesystem-intensive.