3 ms·
The repetition is easy. Any modern Linux distro solved the repetition problem long ago. You don't need systemd monster for that. depend() { need localmou
by snaky 10y ago
The repetition is easy. Any modern Linux distro solved the repetition problem long ago. You don't need systemd monster for that.
depend() {
need localmount
after bootmisc
}
reload() {
ebegin "Reloading configuration"
start-stop-daemon --signal HUP --pidfile ${pidfile} ${command##*/}
eend $?
}
- scrollaway 10y agosystemd the init system is by no means a monster (may I remind you and everyone else again that -resolved is merely a project under the systemd umbrella). I'm not even sure where to begin when addressing a comment like this. You're biased against systemd in the first place so I don't see the point in discussing this. It's really amusing that basic software engineering principles are thrown out of the window the moment things get political.
- snaky 10y agoThe modularity of systemd-the-monster is greatly overrated. The "basic software engineering principles" you are talking about are not about tightly-coupled interdependent in and out ball of mud with no documented protocols and APIs. Things get political that very second back then when systemd crowd started pushing their agenda to the masses using strategies like gentle push.
- vidarh 10y agoYou do, however, need e.g. an init that knows what to do about orphaned processes, or the above is not reliable. It also does not provide any ability to guarantee that process remains running without something other than the typical init, nor to ensure logging is done properly, or enforce resource limits. To provide the features "just" the init replacement part of systemd provides isn't even possible with most other inits, no matter how you write your script.