Hacker News Reader

Comment by nhaehnle | Hacker News Reader

Dependencies between services exist, and for good reason (e.g. various services depending on a database). How do you propose to deal with them?

View on HN

It's pretty basic software design. A few solutions:

1. Web servers return error pages when databases are unavailable. They don't go down.

2. Postfix doesn't die if your virtual maps database server is not available. It waits patiently.

This isn't rocket science.

I'd rather Postfix fail early, than wait until $TIMEOUT to discover that a maps source isn't available.

I think what parent is trying to say in so many words is "I have no use case for tracking service dependencies, therefore it is pointless and should be cut out". An unfortunately common attitude among technical people.

No. I'm saying that relying on startup sequencing is a bad idea full stop.

That's why systemd does dependency tracking and socket activation instead of sequencing.

It needs to do neither of those as well.

You're certainly entitled to your opinion about dependency tracking being an unnecessary luxury, and I'm sure you will find a number of Linux distributions and/or BSDs within your spartan requirements. Not to mention that you can at least for the time being stay with sysvinit (though this won't solve your issue on Debian, since it reads dependencies via a horrible hack in the comments of the init scripts).

I'm a FreeBSD and Windows person so yes you are right.

sysvinit dependency management is horrible as well so I cannot complain about your point there.

But you're not making a good point. If the network goes down, anything which depends on it will also go down. That's a much stronger guarantee than "let's hope this application handles network failure graciously and will kindly start working again as soon as the network is restored".

So the system will be busy starting and stopping services in case of faulty network, instead of having them sit there patiently while the line continues to flap? Great idea - not sure when Cisco will copycat that one, though...

It doesn't really matter either way, because the symptom will be that you can't send mail; either that's how you find out or you have a proper monitoring solution, in which case it doesn't matter whether Postfix actually died or is patiently waiting for the resource to become available. To sum up, I don't see why dependencies need to exist, it seems better to write daemons in such a way that they can deal with temporary absence of resources.

It does matter. Why are you starting postfix if you have no network? You have plenty of use cases where boot speed is actually important.

On a mail server, it is no great improvement to rapidly boot to a state where mail is not working.

Obviously, this was just an example. If you're making an appliance, boot speed matters. If you're aiming for a fast desktop experience, boot speed matters.

This probably hinges on how you define the word "great," but you can diagnose a nonfunctioning mail server a lot easier if it's actually booted up.

Linux is not a service oriented architecture. That is really more of an economic model than a viable model for engineering fault tolerant designs.

Reply on news.ycombinator.com