= phenomenon =
There are a number of services enabled by default in Fedora that do not appear to have ever been reviewed by FESCo for this purpose. Back in 2012, Lennart Poettering made a [http://pkgs.fedoraproject.org/cgit/systemd.git/commit?id=301de5d4da1231689f97aaaa714f76f5834492bf commit] to the systemd package that added a number of entirely new enabled system services. I can't dig up any explanation for the given set and no information is provided as part of the patch.
= background analysis =
I was speaking with Tomas Torcz today who asked if I had any idea why the 'ladvd' service (which provides CDP/LLDP network management services) was enabled by default in Fedora. I could find no reason and tracked it back to this change. As it is a package that listens on the network, it should have had a FESCo approval at some point, but it did not. (The list of approved-by-FESCo services prior to the switch over to carrying them in fedora-release is [https://fedoraproject.org/w/index.php?title=Starting_services_by_default&oldid=377748 here])
= implementation recommendation =
The following services were enabled by default at this time and should be reviewed by FESCo to ensure that they are reasonable to be enabled by default on all of Fedora (as they are now in 90-default.preset), in one or more Editions (by moving them to 80-$EDITION.preset) or disabled by default.
Services without a recorded FESCo approval (that I can locate): chronyd.service auditd.service restorecond.service bluetooth.service cups. abrtd.service abrt-.service acpid.service multipathd.service firstboot-graphical.service gpm.service gpsd.service irqbalance.service ladvd.service libstoragemgmt.service libvirtd.service lm_sensors.service lttng-sessiond.service lvm2-monitor. lvm2-lvmetad. dm-event. mcelog.service packagekit-offline-update.service pcscd. ksm.service ksmtuned.service rootfs-resize.service smartd.service sysstat.service uuidd.service xendomains.service xenstored.service * dirsrv-admin.service
Some of these are probably fine, using no external network resources, but we need to investigate that. If I am wrong and some (or all) of these have a justification on record, please direct me to them. My suspicion is that the list was generated by Lennart running a script over all packages looking for "systemctl enable", but that's pure speculation.
IIRC I generated the initial list from a list of SysV services that were allowed to be on from the fedora wiki somewhere. I figure that page in its state from back then must still exist in the fedora wiki history somewhere, but not sure where...
Replying to [comment:1 lennart]:
If you could point me in the right direction, that would be helpful. (Also, sorry if my initial posting came off as accusatory; rereading it right now I see how it might have sounded that way). That said, it's probably not a terrible idea to use this as an opportunity to look through that list and validate whether we still want all of those presets.
Lastly, I think we should set a policy that the preset file MUST include a comment for each preset, indicating the following:
Does that seem like a reasonable policy decision? It should make it easier for us to keep track in the future of why we have each preset.
We will use the policy proposal in comment 2 moving forward for presets. sgallagh number80 and paragan will review sevices and we will revist list next week.
Leaving the meeting keyword.
I took two days of PTO and came back to five days worth of backlog. Can we postpone this until next week?
Replying to [comment:7 sgallagh]:
auditd.service - FESCo ticket #1311 should have dropped this. '''FIXME'''
No, that ticket is about the in-kernel per-syscall overhead; the existence of auditd was at best a side issue.
In fact the current implementation of #1311 AFAICS requires auditd.service to be ''enabled''.
Next ten... gpsd.service - Default configuration is limited to localhost irqbalance.service - Locally-running service ladvd.service - This service should probably not be enabled by default. It interacts with the external network and changes configuration. '''FIXME''' libstoragemgmt.service - Implicitly approved by FESCo in ticket #876 libvirtd.service - Locally-running service and implicitly approved by FESCo in ticket #544 lmsensors.service - Locally-running service lttng-sessiond.service - Locally-running service. This is also a kernel tracer; we probably want to examine whether it's safe to start this by default (in case this package was pulled in as a dependency, intentionally or otherwise). '''FIXME''' lvm2 - Locally-running service dm-event. - Locally-running service mcelog.service - Locally-running service
Replying to [comment:8 mitr]:
Replying to [comment:7 sgallagh]: auditd.service - FESCo ticket #1311 should have dropped this. '''FIXME''' No, that ticket is about the in-kernel per-syscall overhead; the existence of auditd was at best a side issue. In fact the current implementation of #1311 AFAICS requires auditd.service to be ''enabled''.
You are correct. I misread. So that's fine and we'll list ticket #1311 as the approving item, then.
Replying to [comment:9 sgallagh]:
lttng-sessiond.service - Locally-running service. This is also a kernel tracer; we probably want to examine whether it's safe to start this by default (in case this package was pulled in as a dependency, intentionally or otherwise). '''FIXME'''
As far as I'm aware, this requires the out-of-tree lttng kernel modules. Fedora doesn't provide those at all. I have no idea what lttng-sessiond does when it starts and can't find the modules it needs, but it isn't going to be activating any kind of in-kernel tracer as it is.
Really, this should probably be disabled regardless.
I'm not sure what package requires lttng-tools nor how it got pulled in as a dependency. repoquery on my system doesn't show anything other than its own -devel packages as needing it.
Replying to [comment:12 jwboyer]:
Replying to [comment:9 sgallagh]: lttng-sessiond.service - Locally-running service. This is also a kernel tracer; we probably want to examine whether it's safe to start this by default (in case this package was pulled in as a dependency, intentionally or otherwise). '''FIXME''' As far as I'm aware, this requires the out-of-tree lttng kernel modules. Fedora doesn't provide those at all. I have no idea what lttng-sessiond does when it starts and can't find the modules it needs, but it isn't going to be activating any kind of in-kernel tracer as it is. Really, this should probably be disabled regardless. I'm not sure what package requires lttng-tools nor how it got pulled in as a dependency. repoquery on my system doesn't show anything other than its own -devel packages as needing it.
It's not pulled in on any system I can find. What's odd is that it's configured in systemd presets so that if anyone does pull it in (or someone - possibly maliciously - adds it as a dependency so it gets pulled in without your knowledge) it will auto-start. That sounds wrong to me and based on your feedback above, it probably should be disabled by default anyway.
To summarize, the following services need to be reviewed by FESCo:
My recommendation is that all four of these be removed from the default configuration.
packagekit-offline-update.service should be fine to drop; we don't use the preset system but instead just explicitly enable it, as per http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/
To make things a bit more robust we recommend hooking the update script into system-update.target via a .wants/ symlink in the distribution package, rather than depending on "systemctl enable" in the postinst scriptlets of your package. More specifically, for your update script create a .service file, without [Install] section, and then add a symlink like /usr/lib/systemd/system-update.target.wants/foobar.service → ../foobar.service to your package.
Same thing with the offline update service in dnf-plugin-system-upgrade; it doesn't need a preset because it just directly hooks into system-update.target.wants.
This was commited in https://pagure.io/fedora-release/417f4ea22e8c08f20b186ddea0736b37a9e0283c
Login to comment on this ticket.