Re: networking.service: start operation timed out [SOLVED]
On 8/30/22 8:49 PM, Jeremy Ardley wrote:
> 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.
>
You are right, you should not need to use a cron job to start a
service like haproxy.
I don't use haproxy but I see there is a package for it in the Debian
repos. I think what you are seeing should be reported as a bug in
haproxy if you are using the Debian packaged version. The haproxy
package should start haproxy at the appropriate time during boot,
and systemd provides the ability to make services such as haproxy
depend on certain systemd targets being reached before it tries to
start, such as the network-online target which I think would be
enough for haproxy to start. But in any case, you might report a bug
in haproxy and see if the package maintainers can help you out if
you are using the Debian packaged version.
Best regards,
Chuck
Reply to: