On 17 January 2017 at 10:28, Oberdorfer Patrick patrick.oberdorfer@a1telekom.at wrote:
Thank you very much James for your deep explaining answer! That cleared everything up for me and yes that helped a lot.
Have a nice day :)
No problem, glad it was helpful.
Incidentally if there are services you need ordered after network-online.target you don't need to (and shouldn't) edit the unit files for the services directly.
Instead you should just provide an override with the additional dependency so that systemd merges the two automatically and so future updates of $package don't break on changes to the unit file in /usr/lib/systemd/system and any changes to the unit file get picked up for your system automatically, if the route you go down to resolve your use case is via systemd dependency declaration rather than kernel sysctl or application freebind behaviour.
In the case of nginx, for example, you'd do this:
mkdir /etc/systemd/systemd/nginx.service.d cat > /etc/systemd/systemd/nginx.service.d/after-network-online.conf <<EOF [Unit] After=network-online.target EOF systemctl daemon-reload
This snippet you could drop in for any service that you needed ordering after network-online, ideally via some CM solution like ansible, puppet, chef or saltstack of course.
As an incidental note to this whole thing ... nonlocal_bind and freebind are both viable answers and good methods for handling things like postgres, mysql, haproxy and similar where you need them to bind on a specific IP which is a VIP moved by keepalived (or pacemaker or similar tool) and not always existent on a box without having to start the service after IP is moved via an orchestration (eg via pacemaker) ...
Of course *that* need is avoided if you just tell the app to bind on 0.0.0.0 or :: which, as mentioned, doesn't have these issues and is the default behaviour on a lot of applications, with limiting the connectivity via iptables where it should only be visible on a single interface.
Of course there are occasions where you specifically do need to bind to a specific interface, either to differentiate sshd configs or for other reasons, and that's when the dependency, sysctl and network socket options are various tools to solve the issue.