Posts

Last week for the first time in quite a long time an automated update process failed me. Even though it had been in use for several months already, and had seen numerous successful test runs, one machine was (almost) completely screwed up after the process. It may be interesting to know that all this is taking place on rather "antique" Red Hat 9 systems. I have not had the time to double check whether the following still holds true for more modern systems, any comments are appreciated.The update logs contained a strange line:useradd: unable to lock group file Well, while the message itself is one of the more explicit ones, I could not understand what would be causing a lock on the group file. There is indeed a useradd command in the upgrade script, however it is the only one, and the update takes place right after a reboot. Hence no other process could possibly hold a lock on /etc/group.Looking at the /etc directory I found these two files: /etc/group.lock and /etc/gshadow.lo…

I just hacked together a little FindBugs plugin that will just detect calls to the static Locale.getDefault() method. This may be undesirable for application code to do - e.g. in cases where you have an application framework that provides a more flexible way of localization.This is nothing I deem worthy of contributing to the FindBugs team, because technically there is nothing wrong with Locale.getDefault(). Nevertheless maybe you can use it, too.Just drop it into the plugin directory of your FindBugs installation. The plugin contains the source code of its single class inside the jar. Because this page is not yet full, I post it here as well for a quick glance:package de.shipdown.fb.detect;
import java.util.Locale;
import org.apache.bcel.classfile.Code;
import org.apache.bcel.generic.ObjectType;
import edu.umd.cs.findbugs.BugAccumulator;
import edu.umd.cs.findbugs.BugInstance;
import edu.umd.cs.findbugs.BugReporter;
import edu.umd.cs.findbugs.ba.AnalysisContext;
import edu.umd.cs.…