It's all fixable...

It's all fixable...

Bombing out on unresolved hosts is a CORRECT behavior. Modifying the app so it can work with a certain init system is crazy.

Well, the alternative is fix in resolver library as I've pointed before. And if the application should be fixed in some other cases then it may be done with some kind of "babysitter" wrapper.

So we still need to have explicit dependencies at least for SOME services.

What for? So far all examples were reiterations of the same scheme: "I need the explicit dependencies because I have an application which is broken" and the obvious answer is "well, fix the application"... It can often be done with some kind of wrapper so application itself is intact...

And what if PostgreSQL is down because I'm upgrading it? Or maybe I don't want it to start for some reasons (like system recovery in progress, etc.)?

Then the systemd must be informed and all applications which need the PostgreSQL will wait.

Why should it? I use a connection pool, but it doesn't keep inactive connections forever. So it might certainly be possible that the webapp doesn't have any active connections during shutdown.

If webapp drops all active connections to PostgreSQL while it has unsaved state then it's buggy and should be fixed. If the active connections are closed because there are no work to be done with them then it does not need PostgreSQL to shut down.

Yes. That's why I hate shell scripting and systemd. They work in _most_ cases and can miserably fail in sometimes.

I'm yet to see the problem where systemd fails because of it's design and not because some other component is broken.

Upstart has an advantage of clean _explicit_ dependencies.

IMNSHO it's disadvantage.

They can be analyzed (with the help of systemd!) and fixed if required. But they are _explicit_.

Yup. That's why they'll never be correct. Currently dependency graph is partially stored in application code and partially in upstart configuration. This information is often stale and incorrect - but with some application of time and resources the whole system works - but it only proves the #3 truth from RFC1925. But is it correct and good approach? Obviously not - duplication of information is almost always bad because copies grow apart over time. Sometimes it's needed for performance reason, but I'm not seeing such need with regard to systemd...