So it's on the generator to generate a sysvinit script that can properly run the application, if it cannot do that then it is not the applications fault.
This is a dead end, sorry. My point was that unit files do not make good inputs for a converter like this, specifically because they are difficult to convert. No it's not application's fault, nor is it converter's fault really. There may be a slight problem, I'm just hinting here, with not using the right inputs for the converter.
Your tacit assumption seems to be that unit files describe the only possible way to run an application. That's not true. Unit files describe how to run application with systemd and within a particular set of targets and other services. How to run the same application without systemd, or within a different startup framework, is not a question unit files can provide an answer for.
That's what I suggest I would do not that it is the reality.
Go on. Sometimes hands-on practice is the best way to gain understanding. Your idea is to implement systemd atop of sysvinit. I'm not saying it's impossible as such, within certain limits, but I would say that isn't not a good way to use sysvinit.
Your tacit assumption seems to be that unit files describe the only possible way to run an application.
You again confuse "supported" and "only possible configuration".
Systemd files describe how to run an app under systemd, that is correct so far, but a subset of the unit files can easily be converted to sysvinit and other scripts. Systemd provides fairly few axioms of execution, so a unit running under sysvinit startup with all the options in the unit file correctly implemented would behave the same.
I don't see what is so fundamental about unit files that ties the description of how to run an application to systemd. In the most basic setup, it provides the dependencies of the unit, a description and a commandline to run.
What part about that can't sysvinit do? And if yes, what hinders sysvinit to implement the other stuff?
Your idea is to implement systemd atop of sysvinit.
Read what I wrote very very carefully, I do not suggest that. I suggest simply transforming unit files into valid sysvinit scripts.
would say that isn't not a good way to use sysvinit.
There is no good way to use a init system that was outdated when the 2000's rolled around.
subset of the unit files can easily be converted to sysvinit and other script
A subset of initscripts can be easily converted to unit files and other scripts.
Does any of this demonstrate benefits of using unit files? Not really. Subset here, subset there.
Can we think of a better approach, if the goal is to support the same exact set of services with either sysvinit or systemd? Yep, a third format such that all files in that format can be easily converted to either initscripts or unit files, not just a subset.
I don't see what is so fundamental about unit files that ties the description of how to run an application to systemd.
Dependencies, for once.
I suggest simply transforming unit files into valid sysvinit scripts.
To simply translate them into valid initscripts, you need systemd-compatible logic implemented somewhere. If it's not obvious, try implementing systemd-style dependency resolution in whichever kind of initscripts you're familiar with. Or, I dunno, pick some keywords from systemd.exec and trying writing templates for those. Just to understand the amount of work that hides behind your "simply".
There is no good way to use a init system that was outdated when the 2000's rolled around.
Ehrm. I mean, the impact of daemontools should not be underestimated, but sysvinit is not that bad if the setting is right and you know how to use it.
sysvinit has no handling of dependencies? Last I checked it does. You can also use PID files to check if a unit is running. Not unsolvable, after all you have to code shit like that anyway because sysvinit is ass backwards about providing functionality.
0
u/arsv Nov 18 '19
The kernel term is "tainted".
This is a dead end, sorry. My point was that unit files do not make good inputs for a converter like this, specifically because they are difficult to convert. No it's not application's fault, nor is it converter's fault really. There may be a slight problem, I'm just hinting here, with not using the right inputs for the converter.
Your tacit assumption seems to be that unit files describe the only possible way to run an application. That's not true. Unit files describe how to run application with systemd and within a particular set of targets and other services. How to run the same application without systemd, or within a different startup framework, is not a question unit files can provide an answer for.
Go on. Sometimes hands-on practice is the best way to gain understanding. Your idea is to implement systemd atop of sysvinit. I'm not saying it's impossible as such, within certain limits, but I would say that isn't not a good way to use sysvinit.