Bug 1190488
| Summary: | misbehaves on `init 3` | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | udo <udovdh> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | johannbg, jsynacek, lnykryn, msekleta, s, systemd-maint, vpavlin, zbyszek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-02-09 14:15:10 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
udo
2015-02-08 16:07:55 UTC
It's a known problem. systemd effectively does 'systemctl isolate runlevel-3.target', which kills stuff not in that target. In a sense it *is* what sysvinit did, where it would stop daemons not declared to start in the new runlevel, and start daemons declared to start in the new runlevel. The difference with systemd is that it knows about more stuff, so more stuff gets killed. There were some discussions to change the behaviour to e.g. only kill stuff that is declared as a dependency for the old runlevel, but not for the new one, but I don't anyone ever tried to figure out all the details of what it should do, or tried to work on it. My only recommendation is not to do that. From what I recall SysV init just killed what needed to be killed. This 'systemd' behaviour is unacceptable. What if my enterprise database goes down when I do an init 3? This is a grave fail. Please fix. (My Linux is now more broken than it ever was: logging, runlevels, bloatware, etc. The list grows and grows.) Not every concept can be translated from sysvinit to systemd. If 'systemctl isolate runlevel-3.target' or 'init 3' does not do what you want it to do, use something else. There's no way that it is ever going to do exactly the same thing as in sysvinit, especially since its impossible to say what it did in sysvinit in various corner cases with any certainty. I did `init 3` so I'd like to see `init 3 ` behaviour. From the manual page:
2, 3, 4, 5
Boot into the specified legacy SysV runlevel. These are equivalent
to systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
systemd.unit=runlevel4.target, and systemd.unit=runlevel5.target,
respectively, and provided for compatibility reasons and to be
easier to type.
Please note the word 'compatibility'.
Feel free to comment on the other bug if you have specific ideas for what "systemctl isolate" aka "init <n>" should do. *** This bug has been marked as a duplicate of bug 708537 *** |