On 30/8/22 9:56 am, Ross Boylan wrote:
Now everything just works. Thanks again to everyone. There are probably some general lessons, though I'm not sure what they are. Clearly the systemd semantics tripped me up; it's kind of an odd beast. I understand one of its major goals was to allow startup to proceed in parallel, which is pretty asynchronous. But it has to assure that certain things happen in a certain order, which results in some things being synchronous and blocking. I'm surprised that a tool intended for use from the command line (systemctl) is blocking. Ross
One of my problems with systemd is the that name resolution is by default done by resolved. If resolved was bug free that might be O.K. but it's not - and in a production environment it's not a safe option.
A result of the use of resolved is the start-up and dependency logic. If you start doing things outside of the plan, you run into all sorts of problems. I use bind9 on my various machines and have had to go to some lengths to take resolved out of the equation.
On a similar but different topic. I have a router that connects to an upstream server and also runs haproxy. The upstream connection uses DHCP and IPv6 solicitation. The problem is haproxy fails to start when the upstream connection is not established and configured quickly enough. What would be very helpful is a systemd way to start haproxy when the network is established 'as configured'. So far all I can do is run a cron job to see if haproxy is running and if not, try and restart it. There has to be a better way.
-- Jeremy
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature