On 07/14/2017 07:31 PM, Anton Aylward wrote:
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.
I came to say the same thing. Linda, your system (as described by you) is so different than the stock opensuse that I suspect you're well on your way to writing your own init system. I'd be surprised if anything worked for you the exact way you want it. Good for you. You're way better at this stuff than I am. (I'm rather surprised you start with opensuse, only to customize it so much.) For the Record, my opensuse 42.2 is pretty stock. I've changed very little. My Manjaro system has a lot of tweaking, but still all within the confines of systemd. I've got a server within a softball pitch away from my seat that is still old-school SysVinit from older Suse versions. Its not exposed and its not getting updated any time soon. I always found the old rc way a pain, but finally got adept at doing what I needed with it. Sure, I bitched and moaned about systemd but the learning curve was short, so I learned to do it the systemd way, because I wasn't all that good at the old way either. You change some procedures. Not that big of a deal. Can't help you fix your system in your hypothetical case. Pretty much assumed your question was a rhetorical corner case, but its a corner you live in (and painted yourself into) and I'd be out of my depth playing on your court. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org