Policy regarding service preset enabled (e.g. performance co-pilot)


is there a policy regarding auto-enabling/disabling an installed systemd

I'm asking because installing the dstat replacement[1] in Fedora 29
resulted in 3 additional always running systemd services[2] and 2 open

In contrast, after installing postgresql the postgresql systemd service
has vendor preset disabled (i.e. it is disabled, by default).

Perhaps it's just me, but having 3 services enabled after installing the
dstat replacement ('which strives for 100% output compatibility with the
original dstat') feels like a violation of the principle of least

Best regards

[1]: i.e. pcp-system-tools
cf. <a href="" title=""></a>
[2]: pmcd, pmlogger and pmie


Re: Policy regarding service preset enabled (e.g. performance co

By Nathan Scott at 02/09/2019 - 19:08

Hi Georg,

On Sun, Feb 10, 2019 at 6:47 AM Georg Sauthoff < ... at georg dot so> wrote:
The new dstat script resides in the pcp-system-tools sub-package of
PCP. This package depends on python3, python3-pcp and pcp-libs. None
of these packages contain systemd services.

For folks who are new to PCP, the quick start guide describes the
optional services and some of the tools:
<a href="" title=""></a>

I wonder if you have installed the (optional) pcp-zeroconf package,
Georg? This is a convenience package which automates setup of
frequently needed PCP services for use in customer support situations.
You do not need to install this package to use dstat.

The new dstat does not require running services, by default it runs in
a standalone fashion.
However, you can choose to run it as, e.g.:

$ pcp --host dstat

and it will sample metrics from pmcd(1) on remote host If
you do choose to run the pmlogger(1) service locally, you can use the
new dstat on historical data as well, e.g.:

$ pcp --archive 20190209 --start 2:15pm dstat --time --cpu --disk 2 10

But these are new features missing from the old dstat that are
non-default (i.e. only available if these optional PCP services are
running). The choice is yours.

Agreed - that's why the code is written the way it is, and the
packages are structured the way they are. It is not the case that you
need to have 3 additional services running when using the new dstat.


Re: Policy regarding service preset enabled (e.g. performance co

By Georg Sauthoff at 02/10/2019 - 05:39


On Sun, Feb 10, 2019 at 10:08:51AM +1100, Nathan Scott wrote:
The {pmcd,pmlogger,pmie}.service files are provided by the 'pcp'
package. And pcp-system-tools *does* depend on pcp. See also:

# dnf remove pcp
Dependencies resolved.
Package Arch Version Repository Size
pcp x86_64 4.3.0-3.fc29 @updates 4.2 M
Removing dependent packages:
pcp-system-tools x86_64 4.3.0-3.fc29 @updates 620 k

No, I don't have it installed:

# rpm -q pcp-zeroconf
package pcp-zeroconf is not installed

As-is, because of the dependencies (see above) I have to install them.

Yes, this is true, the service don't need to be running for the new dstat.

The problem is that pmie/pmcd/pmlogger are enabled by default because they have
their 'vendor preset' configured to 'enabled'. See also:

# systemctl status pmie pmcd pmlogger
‚óŹ pmie.service - Performance Metrics Inference Engine
Loaded: loaded (/usr/lib/systemd/system/pmie.service; disabled; vendor preset: enabled)

# find /usr/lib/systemd -name '*.preset' | xargs grep '\<\(pmcd\|pmlogger\|pmie\)'
/usr/lib/systemd/system-preset/90-default.preset:enable pmcd.service
/usr/lib/systemd/system-preset/90-default.preset:enable pmlogger.service
/usr/lib/systemd/system-preset/90-default.preset:enable pmie.service

# dnf provides /usr/lib/systemd/system-preset/90-default.preset
fedora-release-29-7.noarch : Fedora release files

Do I need to create a Bugzilla tickets for fixing the pcp dependencies and
presets or do you take care of it?

Best regards

Re: Policy regarding service preset enabled (e.g. performance co

By Stephen Gallagher at 02/11/2019 - 08:53

On Sun, Feb 10, 2019 at 4:40 AM Georg Sauthoff < ... at georg dot so> wrote:

For the record, a Bugzilla ticket was filed when these were originally
added (and if you looked at 90-default.preset instead of just grepping
it, you'd notice that it was in a comment immediately above those

The BZ is <a href="" title=""></a> and
included the following text when it was filed:


* Does the service listen on a network socket for connections
originating on a separate physical or virtual machine?
Both pmcd and pmlogger can be configured to do so. However, for the
purpose of this bugzilla and being enabled upon install, the default
will be configured for with no listening on network sockets
(adjustable later by the end-user if desired).


Because the default configuration did not (at the time) open any
network sockets for listening, it was approved without FESCo
exception, because it was within the guidelines from
<a href="" title=""></a>

If you are asserting that it now *does* listen on those sockets by
default, that's a problem and we need to open a FESCo ticket.

Re: Policy regarding service preset enabled (e.g. performance co

By Georg Sauthoff at 02/11/2019 - 09:57

On Mon, Feb 11, 2019 at 07:53:57AM -0500, Stephen Gallagher wrote:

Yes, I'm asserting this and I already asserted it in my original mail.

See also:

# ss -lntp | grep 'pmlogger\|pmcd' | column -t
LISTEN 0 5* users:(("pmlogger",pid=6353,fd=9))
LISTEN 0 5* users:(("pmcd",pid=1135,fd=0))
LISTEN 0 5 [::]:4330 [::]:* users:(("pmlogger",pid=6353,fd=10))
LISTEN 0 5 [::]:44321 [::]:* users:(("pmcd",pid=1135,fd=3))

And yes, all I did on that machine regarding pcp was to execute a
`dnf install pcp-system-tools` to get the `dstat` command.

There are basically 2 issues:

1) The dependencies of the package that provides the dstat replacement
(i.e. pcp-system-tools)
2) The vendor presets of the pmlogger/pmcd/pmie services
(which are currently provided by pcp)

Perhaps we can agree to fix the current state to this user experience:

-- User wants to use dstat
=> User learns that the original dstat was replaced by the pcp tool of
the same name
=> User installs the pcp package that provides the dstat replacement
(e.g. pcp-system-tools)
=> User can successfully use the `dstat` command which behaves as the
old dstat command
=> No additional services are running
=> No additional ports are open

There are different ways to improve the user experience in that way:

a) Fix the dependencies of pcp-system-tools such that it doesn't require
the pcp package (which provides the pmcd/pmlogger/pmie services),
b) Change the vendor presets for the pmcd/pmlogger/pmie services to
disabled, or
c) Change the packaging in some other way

Best regards

Re: Policy regarding service preset enabled (e.g. performance co

By Lukas Berk at 02/12/2019 - 22:24


Georg Sauthoff < ... at georg dot so> writes:
Sorry about that, it was a bug in the pcp spec file and how we were
handling pmcd/pmlogger's configuration. Thanks for catching it! I've
submitted a fedora update to fix this and disable listening on network
sockets for pmcd and pmlogger by default on f28,f29 and rawhide.

Please note that outside of this bug, we're in line with fedora
guidelines wrt to enabled services. If individual users wish to deviate
from the vendor presets, they are free to do so.

Looking into this, it may require more than reworking which files are
packed within individual rpms (such as moving the pmda's/pmns components
into pcp-libs). There are some configuration bits also needed wrt to
the metrics namespace that the pcp-system-tools package will also need
changed. We can continue to evaluate it, but it won't be an overnight

PCP maintainers have opted to offer vendor-default enabled pmcd,
pmlogger and pmie services. To reiterate, outside of this spec file bug
(which we've submitted a fix for) we're compliant with fedora guidelines
regarding enabled services. If a user wishes to install
pcp-system-tools and its dependencies, then (like any other package)
is it their responsibility to alter the configuration as desired if it
deviates from the distribution default.


Re: Policy regarding service preset enabled (e.g. performance co

By Tom Hughes at 02/09/2019 - 16:02

There is, yes:

<a href="" title=""></a>

That sounds like it would require an exception.