On 15/07/17 06:11 AM, L A Walsh wrote:
Anton Aylward wrote:
O
Your problem here is not that you CAN'T but that, as you say
I want to be able to use my current recovery methods
Systemd does have beet debug capabilities, but they are different because systemd is not SysVInit.
1) Recovery means I can run xfsrestore from repair mode.
Yes, you can set up a unit to do that, out of the normal boot sequence but accessible via the boot command line. Not a problem.
2) I can try starting 1 more services manually.
Yes you can still do that with systemd.
3) I can look at all of the startup operations in one place for a given service. If I need to make a change in a utility's startup while in emergency -- I can.
By my interpretation of what you are asking for, yes I can do that under systemd. My reservation is that what you say is ambiguous.
4) When I have worked around a problem, I can continue to boot.
That is entirely dependent on HOW you worked around the problem. It may be that with the problem dealt with you can simply reboot. It may be that you want to step though each stage of the boot, one unit at a time, to make sure that there are not further ... complications. Once again, there are many ways to interpret your requirement.
I've had network problems due to naming issues that were very difficult to work with and I wanted the system "up" so I could work on them.
Are we talking about device names, names of the ethernet devices, for example? We've had many threads on that issue! As I understand it, the modern tools allow for over-riding the naming and other tools allow any dynamic naming to be determined. I use NetworkManager and have it set up to configure my primary port with the static name 'eth0' even though it's connection is called 'ethernet-1'. No big deal. YMMV, but the ability to assign static names is there. IT IS NOT A SYSTEMD ISSUE
I should be able to manually bring up the network and start needed services, so I can login from a normal GUI.
Yes, I do that with NetworkManager. OK, so systemd started NetworkManager, but so what? It really doesn't matter if it is started with systemd or or a SysVInit script. It is the NetworkManager that starts, or doesn't, the network connection(s). So I boot, I don't login in at the GUI. I hotkey ctl-alt-f1 to VT1, log in as toot and run the various NetworkManager commands. RTFM.
Oh? How do you continue after a boot problem and not have to restart? If it isn't possible, then please don't claim such methods exist.
It entirely depends on that the problem is.Network problems, file system problems, I've been able to repair without the need to reboot. Even so, sometimes its better to reboot for reassurance that you HAVE rectified the matter and can boot clean.
They don't work. You can't modify or look at the source and rebuild and continue execution. It's not a matter of different, it's a matter of not having basic features.
It is so a matter of 'different'. The difference is this: Long before I encountered UNIX in the mid 1970s, I was taught a few principles of good engineering and good software engineering. You can read those in things like Fred Brooks' "The Mythical man Month" and the works of Ed Yourdon and his associates from those days. The people involved in the UNIX of that era took them to heart and not people are calling them basic UNIX principles. HA! One of them is that using parameters is better than having in-line code. Another is that having parameters in a table, especially a text file that can be modified by an editor, is a good way to work. So we had things like /etc/passwd, a 'database' as text, one like per 'row' with colons as 'column' separators. And simple text tools like 'grep' and 'sed, can easily extract fields. You know all this. A bit more history. The students at BSD took Dennis's work on networks and made a hash of it. Network services had one deamon process per function, each listening on a specific port. That got cleaned up with the 'inet' daemon, listening on all ports and using a comma separated 'database. But that proved inflexible, and was replaced by the Xinet daemon, which is an architectural precursor of systemd, and where the database is replaced with text based unit files, one per protocol or service, which had a a lot more flexibility in many ways. So, how many people were there screaming that the Xinet daemon was a monstrosity, an abomination, and should be ripped out and the God-Sanctioned older inet daemon reinstalled? I didn't notice any. Why the diversion? Well another software architecture BAD practice of the old days was what was termed 'stamp coding'. That is the code in different modules reads, essentially, the same, We can see that throughout SysVInit with the case statements for start/stop/status. In systemd, this has been factored out, just like in the inet daemon the listening and dispatching code has been factored out. Factoring out common code into a parameter-driven 'dispatcher' is good design practice. Could all this have been done in a different way? if we're asking could there be a SysVInit Mk2 that was entirely script driven? We, no, not really. A general 'start-up' feature does things that scripts aren't doing, certainly that that we saw in the Xinet model that the basic inet daemon wasn't doing, such as control over uniqueness, rate of restarts, selective logging, and specific parameters. This is just the beginning of what systemd is addressing. TBC.
BTW, what is a 'beet' debug capability?
s/e/o/g -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org