Bug 1336960 - systemctl preset fails due to missing [Install] section in unit file
Summary: systemctl preset fails due to missing [Install] section in unit file
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-17 22:18 UTC by René Genz
Modified: 2016-07-23 18:48 UTC (History)
12 users (show)

Fixed In Version: systemd-229-9.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-23 18:48:58 UTC
Type: Bug


Attachments (Terms of Use)

Description René Genz 2016-05-17 22:18:07 UTC
Description of problem:
Warning message during installation of package fedora-release-workstation.

Version-Release number of selected component (if applicable):
fedora-release-workstation-24-0.16.noarch

How reproducible:
100%

Steps to Reproduce:
1. start fresh installation on computer with Fedora 24 and select group 'minimal'
2. after reboot in terminal: su -c 'dnf group install -y workstation-product-environment'

Actual results:
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).


Expected results:
No warning message.

Comment 1 Dennis Gilmore 2016-05-18 17:15:25 UTC
fedora-release does not call systemctl enable but does tell the presets to take effect. you do not give enough infomration to redirect or fix the issue. at the least we need to see the full output of the transaction to try and determine what is happening.

Comment 2 René Genz 2016-05-18 21:00:17 UTC
I could not find a component for the package 'fedora-release-workstation', hence I selected 'fedora-release'.
The error message led me to believe 'systemctl enable' is used.

Steps to reproduce can be simplified:
1. reinstall computer with Fedora 24 using installation group 'minimal'
2. after installation and reboot in terminal: su -c 'dnf install -y fedora-release-workstation'


Actual results:
su -c 'dnf install -y fedora-release-workstation'
Failed to set locale, defaulting to C
Last metadata expiration check: 0:57:36 ago on Wed May 18 19:23:28 2016.
Dependencies resolved.
================================================================================================
 Package                                     Arch     Version           Repository         Size
================================================================================================
Installing:
 NetworkManager-config-connectivity-fedora   x86_64   1:1.2.2-1.fc24    updates-testing   104 k
 fedora-release-workstation                  noarch   24-0.16           fedora             23 k

Transaction Summary
================================================================================================
Install  2 Packages

Total download size: 126 k
Installed size: 1.9 k
Downloading Packages:
(1/2): fedora-release-workstation-24-0.16.noarch.rpm            390 kB/s |  23 kB     00:00    
(2/2): NetworkManager-config-connectivity-fedora-1.2.2-1.fc24.x 469 kB/s | 104 kB     00:00    
------------------------------------------------------------------------------------------------
Total                                                           146 kB/s | 126 kB     00:00     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : NetworkManager-config-connectivity-fedora-1:1.2.2-1.fc24.x86_64             1/2 
  Installing  : fedora-release-workstation-24-0.16.noarch                                   2/2 
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
  Verifying   : fedora-release-workstation-24-0.16.noarch                                   1/2 
  Verifying   : NetworkManager-config-connectivity-fedora-1:1.2.2-1.fc24.x86_64             2/2 

Installed:
  NetworkManager-config-connectivity-fedora.x86_64 1:1.2.2-1.fc24                               
  fedora-release-workstation.noarch 24-0.16

Comment 3 Zbigniew Jędrzejewski-Szmek 2016-05-19 04:57:55 UTC
I guess it's systemctl preset misbehaving. It shouldn't print the hint with -q.

Comment 4 Zbigniew Jędrzejewski-Szmek 2016-05-19 12:20:44 UTC
https://github.com/systemd/systemd/pull/3295

Comment 5 Stephen Gallagher 2016-05-19 12:54:34 UTC
I'm not really comfortable just papering over this; we should really try to figure out which preset has been specified for a unit with no install section. That's got to be a bug.

The odd thing is that in this situation, only sshd.socket and sshd.service should be getting the `systemctl preset -q` treatment, and both of those have [Install] sections.

Beyond that, we shouldn't even be calling systemctl preset at all here, because convert_to_edition.lua should be skipping it when we're adding fedora-release-workstation after initial installation.

Zbigniew, is it possible there's a file trigger or something happening that's calling the presets, rather than actually the %post scripts?

And if that's the case, is it just calling `systemctl preset` for all presets? Because that's unexpected behavior. I wrote the convert_to_edition.lua script explicitly for the purposes of not changing the configured services just because you installed a new package. If file-triggers are causing all of the presets to be re-processed, that's going to cause problems.

Comment 6 Zbigniew Jędrzejewski-Szmek 2016-05-19 14:16:57 UTC
There's two sides to this:
- from fedora-release point of view, units which have no [Install] section should indeed not be specified in presets, because it has a curated whitelist.
- from systemd point of view, we want to allow people to add units to presets which cannot be enabled, but potentially might be in the future, etc.

So we probably want to do both, i.e. fix -q, and maybe remove some units from presets in fedora-presets.

>  is it possible there's a file trigger or something happening that's calling the presets

I don't think so.

fedora-release-workstation-24-0.16.noarch.rpm has no scripts, triggers, or filetriggers, and systemd has filetriggers, but they only call daemon-reload. fedora-release-* remains as the likely culprit.

Comment 7 Zbigniew Jędrzejewski-Szmek 2016-05-19 14:27:44 UTC
Oh, wait, it's a bug in systemd after all. It is fixed in git (there was a bunch of work in this area), but not in F24, so I missed that. So yeah, all is fine with fedora-relase.

Comment 8 Zbigniew Jędrzejewski-Szmek 2016-05-19 14:29:31 UTC
... the bug is that "systemctl preset sshd.socket sshd.service" prints a warning. It shouldn't because both of those files have good [Install] sections.

Comment 9 Stephen Gallagher 2016-05-19 14:51:39 UTC
OK, but there's still a bug in fedora-release-workstation somewhere, because it shouldn't actually be calling `systemctl preset sshd.socket sshd.service`. (Changing the default presets just because someone installed this package later is unexpected).

The convert_to_edition.lua package should be reading /usr/lib/variant, seeing that it's already "nonproduct" and then making no changes. (The only time that it should actually apply the preset is if it's called during initial installation of the system, since we don't set /usr/lib/variant until %posttrans.

My best guess is that for some reason, /usr/lib/variant isn't getting set in %posttrans of the fedora-release package, and so the later installation of fedora-release-workstation is unintentionally changing the system from nonproduct to Workstation.

Comment 10 Zbigniew Jędrzejewski-Szmek 2016-05-19 15:18:37 UTC
The bug is easily reproducible:

$ sudo dnf -y --releasever=24 --installroot=/var/lib/machines/fedora-24 --disablerepo='*' --enablerepo=fedora --enablerepo=updates install @"Minimal install"
$ sudo systemd-nspawn -M fedora-24 passwd -d root
$ sudo systemd-nspawn -M fedora-24 -b
# dnf install -y fedora-release-workstation

Comment 11 Stephen Gallagher 2016-05-19 15:30:04 UTC
Yeah, I've confirmed there's a bug in the %posttrans script of the fedora-release package. I'm working up a patch right now.

Comment 12 Stephen Gallagher 2016-05-19 16:29:01 UTC
Patches for fedora-release submitted to pagure.io.

https://pagure.io/fedora-release/pull-request/47
https://pagure.io/fedora-release/pull-request/48

Comment 13 René Genz 2016-05-19 16:50:14 UTC
I am honored to learn from your comments. Thanks for the fix :)

Comment 14 Fedora Update System 2016-07-21 06:47:27 UTC
systemd-229-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-47bda25e7a

Comment 15 Fedora Update System 2016-07-21 18:53:06 UTC
systemd-229-9.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-47bda25e7a

Comment 16 Fedora Update System 2016-07-23 18:48:14 UTC
systemd-229-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.