Mass bug: packages should not auto-enable systemd units
luto at mit.edu
Wed Jun 4 18:29:59 UTC 2014
On Wed, Jun 4, 2014 at 11:23 AM, Adam Williamson <awilliam at redhat.com> wrote:
> On Wed, 2014-04-23 at 16:59 -0700, Andrew Lutomirski wrote:
>> Hi everyone-
>> This is a notice in accordance with the mass bug filing procedure.
>> A number of packages install systemd units and enable them
>> automatically. They should not. Please update these packages to use the
>> macroized scriptlet
>> If your package has an exception from FESCo permitting it to enable
>> itself, please make sure that the service in question is listed in the
>> appropriate preset file.
>> There is a general exception described here:
>> If your package falls under the general exception, then it is possible
>> that no change is required. Nevertheless, if you are relying on the
>> exception, please make sure that your rpm scripts are sensible. The
>> exception is:
>> In addition, any service which does not remain persistent on the
>> system (aka, it "runs once then goes away"), does not listen to
>> incoming connections during initialization, and does not require
>> configuration to be functional may be enabled by default (but is not
>> required to do so). An example of "runs once then goes away" service
>> is iptables.
> The page is somewhat confusingly written, but I don't believe you are
> reading it correctly.
> I believe the page lists *two* general exceptions, not just the one you
> list. Both of the first two paragraphs are exceptions.
> "If a service does not require configuration to be functional and does
> not listen on a network socket, it may be enabled by default (but is not
> required to do so)." is Exception #1
> "In addition, any service which does not remain persistent on the system
> (aka, it "runs once then goes away"), does not listen to incoming
> connections during initialization, and does not require configuration to
> be functional may be enabled by default (but is not required to do so)."
> is Exception #2
> I don't quite understand why these are written entirely separately, as
> so far as I can see, #1 entirely subsumes #2: anything excepted by #2 is
> also excepted by #1.
> The big difference here with what you wrote in your email is that a
> service does not have to be one-shot to be covered by the exception. The
> only requirements to be excepted are i) 'does not listen on a network
> socket' / 'does not listen to incoming connections' (these seem
> basically the same to me) and ii) 'does not require configuration to be
> I'm not sure if any of the packages you filed against are covered by
> Exception #1 (one which I'm fairly sure is covered is 'at', but I don't
> see that you actually filed a bug against it), but if I'm right, you
> might want to check.
I haven't explicitly checked either one, actually. What I did was to
search for packages that enabled systemd units on their own instead of
using the preset mechanism. For the most part, packages should be
using presets to enable units. There are a couple packages I filed
bugs against that do, indeed, qualify for the exception and have now
migrated to using presets and are now in the default preset list.
That being said, there are certainly false positives here, due to my
somewhat buggy script and the fact that I'm using data that's a bit
stale. Is there a better way to download all the spec files than to
grab them one at a time by scraping pkgs.fedoraproject.org's web
interface? That's how I got my current copy, and I don't relish
More information about the devel