Created attachment 747646 [details] anaconda.program.log with the failing 'services' line at 305:306 Description of problem: Anaconda kickstart 'services --disable' configuration ignores existing services when the <list> contains service/s that don't exist. I would expected the non-existent services to 'fail' at being disabled, but the existing ones to be enabled. Unfortunately, late discovery of this issue has lead to some machines having sshd enabled by default when they should not have. I seem to recall that under the older behaviour, such as RHEL, this would not cause as in issue where sshd would be enabled as seen with systemd. Version-Release number of selected component (if applicable): anaconda-19.25-1.fc19.x86_64 systemd-204-2.fc19.x86_64 How reproducible: Every time (this behaviour is reproducible on F18, F19A and current F19development) Steps to Reproduce: 1. Take a kickstart file 2. Explicitly place (as an example) ssh in %packages (thus forcing it's install) 3. Explicitly place (as an example) -bluetooth -firstboot -httpd -pcsd (on separate lines) the %packages section (thus ensuring they're not installed) 4. Place 'services --disabled=bluetooth,firstboot,httpd,pcsd,sshd' as one of the kickstart configuration lines 5. Install the system Actual results: (using the above example) sshd is enabled by default anaconda.program.log indicates error of 'no such file or directory' but doesn't actually say which service it couldn't find (see attached, lines 305:306) Expected results: (using the above example) sshd is disabled by default anaconda.program.log indicate the attempt to disable a non-existent service Additional info: I don't know enough about anaconda/systemd to be sure this is an anaconda bug or systemd, however I've filed against anaconda as the behaviour is triggerable via kickstart.
I think this is probably a systemd issue, its manpage indicates you can pass multiple services so it should be doing the right thing and disabling the ones it can. The same should be done for enable if it doesn't already.
Hm, it seems that systemctl actually performs the action, but the output is misleading: $ sudo systemctl disable sshd.service rm '/etc/systemd/system/multi-user.target.wants/sshd.service' $ sudo systemctl enable sshd.service ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service' $ sudo systemctl disable sshd.service goo.service Failed to issue method call: No such file or directory $ ls -l '/etc/systemd/system/multi-user.target.wants/sshd.service' ls: cannot access /etc/systemd/system/multi-user.target.wants/sshd.service: No such file or directory The informational line of 'rm ...' or 'ln -s ...' is shown only when the whole operation succeeds. It would be nice to get this output for the units which where disabled/enabled along with the error message. Also the error message really should show the name of the failed unit.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #2) > Hm, it seems that systemctl actually performs the action, but the output is > misleading: I agree with the output being misleading, but it seems there's actually a worse problem: The result of the operation depends on the order of the services given on the command line. Existing services seem to be ignored if they are listed after a non-existent one.
This should be fixed by commit 02b9e969. We now allow to delete symlinks to removed units too. In case of non-existing unit which was never present on the system thus never enabled, there are no symlinks to delete and operation exists without error.
Thanks for working on this one folks. I'm wondering about #4, though (without testing the change) Currently, in at least F18, if a request is made to enable a singular non-existing unit systemctl exits returning 1. $ sudo systemctl disable boinc-clientasdasdasd dfkjlghdflkgj Failed to issue method call: No such file or directory $ echo $? 1 I'm wondering if #4 means this exit behaviour has changed, or whether exit behaviour differs depending on the number of services referenced in the systemctl request. I'd like to think that what should happen would be to disable/enable all units requested, then throw errors for the non-existing units and return 1. The idea of exiting without error gives me, as a sysadmin, the worries. A workaround exists to call 'systemctl status' first but this seems a little clunky. To my mind, anything that doesn't work as intended should return a non-0. However, I understand that such behaviour would permit anaconda to continue installing when using a generic template of services to enable, as per my original report. Minor though bubble: calling start/stop on non-existent units should complete as many units as possible and throw an error listing the ones that can't. Anaconda should handle this in the 'services' line by using an additional (optional) '--strict' like keyword that would stop installs on non-existent 'services'.
(In reply to Peter Lawler from comment #5) > Thanks for working on this one folks. I'm wondering about #4, though > (without testing the change) > > Currently, in at least F18, if a request is made to enable a singular > non-existing unit systemctl exits returning 1. > > $ sudo systemctl disable boinc-clientasdasdasd dfkjlghdflkgj > Failed to issue method call: No such file or directory > $ echo $? > 1 > > I'm wondering if #4 means this exit behaviour has changed, or whether exit > behaviour differs depending on the number of services referenced in the > systemctl request. I'd like to think that what should happen would be to > disable/enable all units requested, then throw errors for the non-existing > units and return 1. Yes, the behaviour is changed. Right now we will delete links to an existing service, no matter whether the service file exists or not. This means that it's not possible to error out if the service file doesn't exist, and systemctl has no way to distinguish between a service name being "invalid" and service being nonexistent. This is a drawback, but less important than the benefits of the change. > Minor though bubble: calling start/stop on non-existent units should > complete as many units as possible and throw an error listing the ones > that can't. This would be pretty fragile.
commit 02b9e969
systemd-204-18.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-204-18.fc19
Package systemd-204-18.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-204-18.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23072/systemd-204-18.fc19 then log in and leave karma (feedback).
systemd-204-18.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.