I have now uploaded lbcd 3.5.0-1 to the archive. This contains what I
believe to be a full implementation of systemd and upstart compatibility
for a UDP-based daemon from both an upstream and packaging perspective,
including dealing with some upgrade issues from previous bad decisions I'd
made (as documented in the previous message).
I'd welcome commentary or critique on anything I did incorrectly or not in
keeping with the spirit of one of the init systems. I was unable to do
the same for OpenRC since I didn't have documentation or a test platform.
By full, I mean:
* upstart synchronization via SIGSTOP added as a command-line option.
* systemd synchronization support added via sd_notify.
* systemd socket activation support.
* Upstream source installs unit files per daemon(7).
I did this because I wanted to get a feel for everything that was involved
in fully implementing upstream's recommendations.
In addition, the Debian packaging provides a native upstart configuration
file, and includes the upgrade code that I discussed in my previous
message. I did not attempt to support NO_START on upgrades for upstart
systems, pending a better resolution of the update-rc.d issue.
I'll have more to say about the relative merits of the two init systems
later, but one thing I wanted to not briefly: this exercise was extremely
valuable in helping me get a more realistic picture of both init systems.
I had gone into this exercise with the vague impression that they were
roughly at feature parity, and now realize that is not the case.
My impression now is that systemd's init and service management component
is a substantially more mature piece of software. That's an odd thing to
say given that upstart is older, but systemd has the feel of software
that's been tested against a wide variety of different situations and has
had the necessary adaptations and configuration added to meet those needs.
In some cases, that's "simply" additional features; in some cases, that's
more comprehensive and more scalable design. The socket activation system
in particular is night and day between the two systems.
I spent more time working on systemd integration than upstart integration,
but that's because systemd brought so much more to the table and I got
much more benefit out of it. Integrating with upstart felt like
janitorial work: do things this way instead of that way, debug some
things, and now I'm back to basically the same functionality as I had with
an init script except without all the forking and PID files. I don't mean
to understate that, but I had that experience a decade ago with
daemontools, so it isn't horribly exciting. systemd, on the other hand,
inspired me to experiment and to design because it felt like it was
tackling larger problems and taking a broader view. When doing systemd
integration, I felt like I was making the software better in concrete and
measurable ways, as opposed to just satisfying an integration requirement.
I also want to call out the design of systemctl status, which is an
absolutely lovely tool and which single-handedly sold me on the benefits
of the systemd journal (something about which I was previously quite
dubious). Being able to run one command and see nearly everything of
relevance to my daemon including all of its recent log messages was a
delight, both as a developer and as a systems administrator. The systemd
folks did a great job here.
For those who haven't seen it, here's sample systemctl status output:
lbcd.service - responder for load balancing
Loaded: loaded (/lib/systemd/system/lbcd.service; enabled)
Active: active (running) since Sat 2013-12-28 17:18:11 PST; 40s ago
Docs: man:lbcd(8)
http://www.eyrie.org/~eagle/software/lbcd/
Main PID: 3465 (lbcd)
CGroup: name=systemd:/system/lbcd.service
└─3465 /usr/sbin/lbcd -f -l
Dec 28 17:18:11 wanderer systemd[1]: Starting responder for load balancing...
Dec 28 17:18:11 wanderer lbcd[3465]: ready to accept requests
Dec 28 17:18:11 wanderer lbcd[3465]: request from ::1 (version 3)
Dec 28 17:18:11 wanderer systemd[1]: Started responder for load balancing.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
