Big thanks to Martin Mois for implementing a
recent feature request
to relax the rules for semantic versioning
enforcement in japicmp when the current
project version is less than 1.0.0
.
My basic problem was that I wanted to configure the plugin once in
the primogenitor POM and
then have the semantic versioning check automatically start working
when the API is marked as stable (in other words, when it reaches
1.0.0
). Without the feature above, I'd have had to redeclare the
plugin's configuration in every project, disable it, and then remember
to re-enable it every time a project reached 1.0.0
.
First public release of jregions.
Unfortunately, the Travis CI build
is failing because 0.0.1
was never deployed to Central. This means that
when japicmp tries to analyze the API
against the old version of the library, it can't find the old version. This
will self correct when 0.0.3
is released.
The next step is to move any libraries that
were using jareas or
jboxes over to jregions
. That's
jcanephora,
r2, and jsycamore,
at the very least.
For about a week, I've been having DNS resolution issues on one server. The machine runs a tinydns server for publishing internal domain names, and it seemed that after roughly 24 hours of operation, the server would simply stop responding to DNS requests. After exhausting all of the obvious solutions, I restarted the jail that housed the daemon and everything mysteriously started working.
I checked the logs and suddenly realized that there were no messages
in the log newer than about a week. I checked the process list for
s6-log instances and noticed that no, there were
no s6-log
instances running in the jail. I checked
/service/tinydns/log/run
, which looked fine. I tried executing
/service/tinydns/log/run
and saw:
exec: /usr/local/sbin/s6-setuidgid: not found
OK. So...
# which s6-setuidgid /usr/local/bin/s6-setuidgid
Apparently, at some point, the s6
binaries were moved from
/usr/local/sbin
to /usr/local/bin
. This is not something I did!
There was no indication of this happening in any recent
port change entry nor
anything in the s6 change log.
The "outage" was being caused by the way that logging is handled. The
tinydns
binary logs to stderr
instead of using something like
syslog, with the error messages being piped
into a logging process in the manner of traditional UNIX pipes.
This is normally a good thing, because syslog
implementations haven't
traditionally been very reliable. The problem occurs when the process
that's reading from the standard error output of a preceding process
stops reading. Sooner or later, any attempt made by the preceding process
to write data to the output will block indefinitely (presumably, it
doesn't happen immediately due to internal buffering by the operating
system kernel). In a simple
single-threaded design like that used
by tinydns
, this essentially means the process stops working as the
write operation never completes and no other work can be performed in
the mean time.
I'm currently going through all of the service entries to see if anything else has quietly broken. Perhaps I need process supervision for my process supervision.
Had a minor outage yesterday apparently due to a bug in the older FreeBSD images that DigitalOcean provide. To their credit, they responded extremely quickly to my support request and provided a link to a GitHub repository with a fix that could be applied to live systems.
A close friend of mine suggested that this blog might be more readable with a glossary, and I agreed. Computer science is fraught with terms that may have one of several similar-but-not-quite-the-same meanings depending upon the context in which they're used. I've added a glossary that I'll try to keep updated and will link to from the first uses of significant terms when they arise. Note that the glossary tends towards definitions from the perspective of this blog. That is, it lists only my intended definitions of terms as opposed to listing every possible accepted definition of each of them. I've gone back through old posts and tidied up the usages somewhat. I'll be making an effort to use more consistent terminology from now on.
I also took this opportunity to aggressively modularize the zeptoblog codebase and introduce a general API for implementing post generators. The glossary page is an implementation of a post generator that builds a static page from a database of definitions.