Hide Forgot
Description of problem: If systemctl preset is called on unit file that is disabled and its default preset state state is also disabled, then systemd will not alter current unit file state, but systemctl prints following 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, ...). Version-Release number of selected component (if applicable): systemd-219-27.el7.x86_64 How reproducible: always Steps to Reproduce: 1. yum install rsync (should provide /usr/lib/systemd/system/rsyncd.service) 2. systemctl daemon-reload 3. systemctl show -p UnitFileState,UnitFilePreset rsyncd.service UnitFileState=disabled UnitFilePreset=disabled 4. systemctl preset rsyncd.service Actual results: systemctl prints, 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 action is taken by systemd and systemctl prints no message and returns with exit code 0. Additional info: This is already fixed upstream, https://github.com/systemd/systemd/commit/39207373dd638e548019ddb49929f15795b8b404
fix merged to upstream staging branch -> https://github.com/lnykryn/systemd-rhel/commit/f96f6b6ee9fbe41ee411cb428256bd085cbef4f8 https://github.com/lnykryn/systemd-rhel/commit/5f273838f41f27e0045395c1677272d9dd12496c -> post
Verified with systemd-219-30.el7. Old package: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: systemctl preset without [Install] section :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ BEGIN ] :: Running 'systemctl daemon-reload' :: [ PASS ] :: Command 'systemctl daemon-reload' (Expected 0, got 0) :: [ BEGIN ] :: Running 'systemctl preset rsyncd.service' 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, ...). :: [ PASS ] :: Command 'systemctl preset rsyncd.service' (Expected 0, got 0) :: [ BEGIN ] :: Running '[[ -r /var/tmp/tmp.MFt51eAMlo && ! -s /var/tmp/tmp.MFt51eAMlo ]]' :: [ FAIL ] :: Command '[[ -r /var/tmp/tmp.MFt51eAMlo && ! -s /var/tmp/tmp.MFt51eAMlo ]]' (Expected 0, got 1) New package: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: systemctl preset without [Install] section :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ BEGIN ] :: Running 'systemctl daemon-reload' :: [ PASS ] :: Command 'systemctl daemon-reload' (Expected 0, got 0) :: [ BEGIN ] :: Running 'systemctl preset rsyncd.service' :: [ PASS ] :: Command 'systemctl preset rsyncd.service' (Expected 0, got 0) :: [ BEGIN ] :: Running '[[ -r /var/tmp/tmp.jizxInWtIb && ! -s /var/tmp/tmp.jizxInWtIb ]]' :: [ PASS ] :: Command '[[ -r /var/tmp/tmp.jizxInWtIb && ! -s /var/tmp/tmp.jizxInWtIb ]]' (Expected 0, got 0)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2216.html