4 ms·
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 d
by d0 13y ago
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.
- nailer 13y agoI'd rather Postfix fail early, than wait until $TIMEOUT to discover that a maps source isn't available.
- mercurial 13y agoI 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.
- d0 13y agoNo. I'm saying that relying on startup sequencing is a bad idea full stop.
- the_mitsuhiko 13y agoThat's why systemd does dependency tracking and socket activation instead of sequencing.
- d0 13y agoIt needs to do neither of those as well.
- mercurial 13y agoYou'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).
- d0 13y agoI'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.
- mercurial 13y agoBut 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".
- mydecombinator 13y agoSo 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...
- andreasvc 13y agoIt 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.
- mercurial 13y agoIt does matter. Why are you starting postfix if you have no network? You have plenty of use cases where boot speed is actually important.
- pekk 13y agoOn a mail server, it is no great improvement to rapidly boot to a state where mail is not working.
- mercurial 13y agoObviously, 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.
- cwyers 13y agoThis 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.