UPDATE: could not reproduce in Rocky Linux 8.5 nor Ubuntu 20.04, detailed in issue #1344
On Sun, Apr 3, 2022, 12:16 Jim Klimov <jimklimov+...@gmail.com> wrote: > Hello all, > > A concern was raised (in issue #1344 among other things dealing with > recent git-source NUT setup on Rocky Linux 8) that new systemd service > definitions misbehaved on a client-only system. > > Per report, the `nut-monitor.service` (which both `Wants` and is `After` > the `nut-server.service`) did not even try to start on a system without a > `nut-server` unit defined (if I got their setup right) until the "After" > constraint was removed (`Wants` is still there), e.g. it was not > auto-starting upsmon after a reboot. I can't exclude that the issue got > fixed by something else done during investigation, though. > > My understanding was that `Wants` is a weak dependency - telling systemd > to try starting stuff and move on (unlike `Requires` or `Requisite` that > consider success of that attempt), and `After` queues the start of current > unit to begin after the listed one gets into a definitive state (or > necessarily success?). > > If it really does not work like that when the listed unit is not known > (and/or is known but masked and may not start ever?), I'm in for a bit of > surprise =D and would welcome suggestions about optional dependencies of > this sort. > > It can also help if people try to reproduce the situation in their Linux > distros (old and new), maybe something works differently in various systemd > versions out there. > > At least, this is something to get a better understanding of before > cutting a release. > > Thanks in advance, > Jim Klimov > > > On Fri, Apr 1, 2022, 02:01 Jim Klimov <jimklimov+...@gmail.com> wrote: > >> Hello, fellow NUTs! >> >> It is with a [happy] heart that I must proclaim today, that the long >> reign of NUT v2.7.4 is coming to an end. Its anticipated successor of half >> a dozen years, release-in-waiting NUT v2.7.5 has also quietly expired, and >> [won't] be sorely missed. They were survived by the next name in line, NUT >> v2.8.0(-rc1). Le NUT est mort, long live the NUT! >> >> Along just this leg of the journey, NUT codebase survived at least four >> separate CI farms and technologies to make its builds easier and more >> reliable, all while succeeding on a wide range of CPU and OS platforms, >> ranging from current distros to the dawn of millenium (nearly-immutable >> appliances and sturdy reliable servers matter too!), as well as multiple >> generations and implementations of compiler toolkits, "make" and scripted >> code interpreters involved. >> >> We are grateful to the many freely available projects, services and >> communities who helped us in particular (maybe unwittingly) and the FOSS >> ecosystem in general (intentionally), such as (and not limited to) >> Asciidoc, Autotools and family, BuildBot, CCache, Clang/LLVM, FossHost, >> GCC, GitHub, Google, illumos, Jenkins, LiberaChat, Proxmox, QEMU, >> StackExchange, Travis, ZeroMQ... bits here, swathes there - it would have >> been much harder without the likes of them (and many others). >> >> Advances in compiler code analysis in particular, as is seen on a daily >> basis with CI non-regression builds across the range of 10 major releases >> of clang and 7 of gcc, is immense. At times annoying, yes, but it led to a >> great cleansing of the codebase from questionable code (and indeed some >> potential bugs). And it was possible to do so in a way that all those >> regularly tested systems are satisfied, so the codebase stays clean and >> green and portable as we iterate new contributions, and merged with peace >> of mind many ports and features from long-awaited branches (such as >> libusb-1.0+0.1 support finally), or forks (notably 42ity/nut). >> >> Let me take a moment to tender our special thanks from both the >> maintainer team and countless users of UPS, ePDU, solar panel and similar >> hardware, to numerous personal and corporate contributors of new drivers >> and features or fixes for existing ones, as well as to community members >> who ask and answer questions, and who log github issues with their ideas, >> experiences or grievances. >> >> As always we would welcome people willing to regularly share their >> expertise in certain areas and tools (in particular, thanks @nbriggs for >> solving many practical mysteries around USB bit-stream lately), or >> protocols (more active experts on prolific Qx family would be great for PR >> reviews), or packaging, service and distro integrations, or HCL/DDL >> maintenance based on reports trickling in... just about anything! >> >> While we have a lot of features queued to complete or port for the next >> releases (hopefully with a healthier cadence), we expect to see more >> feedback by exposing thevrelease, and hope for little fallout from the many >> changes made while cleaning up the warnings. >> >> Handing over to creative packagers now... >> >> Jim Klimov, >> on behalf of the Network UPS Tools Project >> >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser