Description of problem: # systemctl | grep maint cpuspeed.service loaded maintenance maintenance rpcgssd.service loaded maintenance maintenance It's in red, so it must be important. Don't see it documented anywhere obvious in the man pages, though. Version-Release number of selected component (if applicable): systemd-3-3
Also, systemctl doesn't disable the color when it's talking to a pipe... it should.
Services appear to go into maintenance when startup fails: systemd[1]: Got SIGCHLD for process 693 (ip6tables) systemd[1]: Child 693 died (code=exited, status=6/NOTCONFIGURED) systemd[1]: Child 693 belongs to ip6tables.service systemd[1]: ip6tables.service: control process exited, code=exited status=6 systemd[1]: ip6tables.service got final SIGCHLD for state start systemd[1]: ip6tables.service changed start -> maintenance I think a better term is needed, perhaps "failing". And perhaps it could use the exit status and for example report "not configured" in the above case.
The term is actually taken from Solaris SMF where a similar state exists for services. We thought it would be a good idea to reuse the same terminology used in other systems as far as that makes sense. I have now documented the state in the man pages in git upstream.
Please reconsider using "failing" or "broken" instead. This will save a lot of support requests later. "Refer to the docs" is one answer, but "it's obvious" is better. The system isn't in widespread use and this is already the second confused person I've seen. Third, if you count me.
I like "failing" or "failed" - this is a typical "bad" word one looks for in logs.
Well, "failing" is not the right word, because it already failed. Note that I think "broken" and "failed" are too strong words. A non-zero code does not necessarily mean that something is really broken, just that it needs somebody to look into. Also, again, this is a name we jacked from Solaris, and I am not sure we should innovate in this area. I am open to change this, but I don't think that "broken" or "failed" are better choices than "maintenance".
(In reply to comment #6) > Note that I think "broken" and "failed" are too strong words. A non-zero code "non-zero exit code" that is.
"Failed" is probably better than "broken", because it's less strong. And it sounds a little more business-y than "broken", making it a nice middle ground between the _very_ jargon-y term "maintenance".
Furthermore, 'failed' is pretty standard parlance for things that return non-zero exit codes. It's what the old sysv wrapper printed in that case, etc.
Yep. I agree with "failed" as well.
Created attachment 441325 [details] changes "maintenance" to "failed" throughout Patch against current git. Changes maintenance to failed everywhere, except where the word is used to mean actual maintenance, which it is a couple of times in the documentation. Applies and compiles cleanly. Will test soon. :)
Comment on attachment 441325 [details] changes "maintenance" to "failed" throughout Wait, attached older file. Hold on.
UNIT_FAILED is already used in the code. So my naive change doesn't work. Please hold. :)
Created attachment 441327 [details] patch to change 'maintenance' to 'failed' This patch changes the old UNIT_FAILED to UNIT_ERROR, so there is no conflict. And now everything works great. Slight bit of testing, even.
ok, will merge this patch.
Thanks man. :)
Fixed now upstream.
systemd-9-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-2.fc14
systemd-9-3.fc14, initscripts-9.18-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.18-1.fc14
initscripts-9.19-1.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.19-1.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-9-3.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts sysvinit systemd'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-9-3.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
systemd-10-1.fc14, initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update systemd initscripts sysvinit'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/systemd-10-1.fc14,initscripts-9.20-1.fc14,sysvinit-2.87-5.dsf.fc14
initscripts-9.20-1.fc14, sysvinit-2.87-5.dsf.fc14, systemd-10-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.