The answers are there, you just don't want to admit they are right answers...
Posted May 27, 2010 8:01 UTC (Thu) by khim
In reply to: The road forward for systemd
Parent article: The road forward for systemd
I have an application which bombs out if BIND is not yet started (it needs a resolver to resolve host names when it reads its config). How do I mark this dependency?
If the application bombs out before something is started then the application should be fixed - it's as easy as that. It can connect to bind (then it'll be stopped till bind is started) or we can fix the resolver library to block the application till the bind is started (exactly the same thing, but more clear solution).
Or another thing, with upstart I can specify that my another application depends on PostgreSQL. So there's no sense in running it if Postgres is not started or is disabled. I don't want it to be stuck forever waiting for connection.
You either need the application, or you don't need it. If you need it then start it and PostgreSQL will be started, if you don't need it then don't start it.
Another painful area - stopping services.
What's so painful about it?
I want my init system to correctly traverse and carefully deconstruct dependency graph. For example, I want my webapp to be stopped before PostgreSQL is stopped.
Your webapp will be stopped before PostgreSQL if it keeps the connection to PostgreSQL active - as it should.
Look, the Unix survived for 40 years as a research project - and a lot of components are connected via ducttape and chewing gum. This is crazy. If it's production system then it should be built as production system. systemd removes the chewing gum and ducttape - and there are no way to reattach them. This means components which don't fit without ducttape must be changed to fit better, that's all. If you don't like it - you can use the old system, if you want, it's free software, after all.
to post comments)