On 14/07/17 08:42 PM, L A Walsh wrote:
You certainly CAN have other thins and other ways to start systems, run tasks, do If-this-then-that sort of jobs. I have jobs running in systemd computers that have migrated from older systems and didn't have change anything to get them to run. Ok, simple "want". I want to run my own 'init' process as pid=1. I want to be able to use my current recovery methods when things go south, including being able to bring up a system by manually starting each script "by hand" from a shell -- being able to easily determine
John Andersen wrote: the proper starting order by listing a directory or file.
To start system: run all 'start scripts in "xxx" in the order specified by "yyy".
Where, ideally it separates out HW boot tasks from system services...
So for sysV-start, I can cd to /etc/init.d/boot.d and run the "S" scripts in the order shown. If I don't feel confident about all of them, I can run any subset of them, then I can try for either single or multi user...
I've had times where some problem prevented an automatic boot, and the only way I had my system up was by manually starting everything from the 'emergency console' and using it (for a few weeks) from there.
From what I've seen and experienced, you just can't do that w/sysd.
That's my biggest obstacle in using systemd to control a normal automated boot, at this point. I don't know how many other show stoppers might be in the way -- but sysd's lack of configurability prevents it from running unless I give up my right to manually debug, fix, and continue a system's startup.
If you wanted an example of its inflexibility -- this is pretty much the first I run into which aways scares the *** out of me. ;-(
If this is no longer a problem, please let me know, and I can move forward (though working on my system booting, is not a real high priority task right now -- am just focusing on the "using" of it. ;-)
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. They exists. They work differently. And if you try to use your old methods you will find they don't work because this is systemd not SysVInit or the BSD-like ad-hoc scripting set. There's the old tale about 'how to capture a money, with the chained vase and the candy'. https://www.theguardian.com/lifeandstyle/2014/nov/14/how-to-avoid-monkey-tra... At https://fedoraproject.org/wiki/How_to_debug_Systemd_problems there is a section on "Systemd boot parameters" The first example, "systemd.unit=", offers the ability for you to write your own unit or series of units - the sequence you talk of - to do specific things that are different from a normal boot. That may be to simply give you a shell and you can do individual 'systemctl' to run arbitrary units, some of which may be your own creation. There's a lot of potential here for experimentation to find what best suits your specific needs. -- 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