Chuck Zmudzinski writes:
> On 8/31/22 11:03 AM, Jeremy Ardley wrote:
> It also seems to be a ridiculously long time (ten minutes) for your provider
> to configure your interface. I would look for a different provider if they
> can't or won't fix it.
Or maybe just create an overlay for the haprox
On 8/31/22 11:03 AM, Jeremy Ardley wrote:
> On 31/8/22 10:45 pm, Chuck Zmudzinski wrote:
> >
> > 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
On 31/8/22 10:45 pm, Chuck Zmudzinski wrote:
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
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 a
On 31/8/22 9:16 pm, Anssi Saari wrote:
I wonder what bugs Jeremy has found and reported against
systemd-resolved though. I remember getting a big headache trying to get
interface specific DNS configuration going only to eventually find out
it really wasn't working in the version Debian packaged
Greg Wooledge writes:
> On Wed, Aug 31, 2022 at 08:49:29AM +0800, Jeremy Ardley wrote:
>> One of my problems with systemd is the that name resolution is by default
>> done by resolved.
>
> Not in Debian.
>
> unicorn:~$ systemctl status systemd-resolved
> ● systemd-resolved.service - Network Name
On Wed, 2022-08-31 at 08:49 +0800, Jeremy Ardley wrote:
> A result of the use of resolved is the start-up and dependency logic.
Another problem I had with systemd-resolved on an Ubuntu box was that
it refuses to forward single part names to the DNS server it got by
DHCP (names like 'printer1' as o
On Wed, Aug 31, 2022 at 08:49:29AM +0800, Jeremy Ardley wrote:
> One of my problems with systemd is the that name resolution is by default
> done by resolved.
Not in Debian.
unicorn:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib
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 st
The bind9 script I created in /etc/resolvconf/update.d executed
systemctl reload named
near the end (if systemd is active, which it is for me). Adding set
-x to the script showed that this was where the process of bringing up
the interfaces hung up.
named is obviously not active when the ne
Thanks Andrew, Felix, Jeremy, Anssi, Curt, Tomas and Greg for your
suggestions and comments.
I followed several of them by trimming my network/interfaces file to
nothing and then slowly adding stuff back.
The blank file and the one with only the loopback worked:
networking.services reported succe
On Sat, Aug 27, 2022 at 09:07:49PM +0800, Jeremy Ardley wrote:
> Further to my longer reply on this list, there are three separate network
> configuration & management services that can be running at the same time on
> a debian system
>
> * networking.service
> * systemd-networkd.service
> * Ne
On 27/8/22 8:25 pm, to...@tuxteam.de wrote:
On Sat, Aug 27, 2022 at 11:55:44AM -, Curt wrote:
On 2022-08-27, Jeremy Ardley wrote:
I'd appreciate any suggestions about how to diagnose or cure the
problem. I have set VERBOSE=yes in /etc/default/networking
First of all ensure NetworkManag
On 27/8/22 7:55 pm, Curt wrote:
On 2022-08-27, Jeremy Ardley wrote:
I'd appreciate any suggestions about how to diagnose or cure the
problem. I have set VERBOSE=yes in /etc/default/networking
First of all ensure NetworkManager is really dead.
Your advice and the advice of Andrew M.A. Cater
On Sat, Aug 27, 2022 at 11:55:44AM -, Curt wrote:
> On 2022-08-27, Jeremy Ardley wrote:
> >>
> >> I'd appreciate any suggestions about how to diagnose or cure the
> >> problem. I have set VERBOSE=yes in /etc/default/networking
> >>
> > First of all ensure NetworkManager is really dead.
>
> Y
On 2022-08-27, Jeremy Ardley wrote:
>>
>> I'd appreciate any suggestions about how to diagnose or cure the
>> problem. I have set VERBOSE=yes in /etc/default/networking
>>
> First of all ensure NetworkManager is really dead.
Your advice and the advice of Andrew M.A. Cater appear
to be antithetic
On Fri 26 Aug 2022 at 22:37:08 +, Andrew M.A. Cater wrote:
> On Fri, Aug 26, 2022 at 03:06:24PM -0700, Ross Boylan wrote:
> > In Debian 11/bullseye my system keeps reporting timeouts while trying
> > to bring up the first non-loopback interface. According to ip, the
> > interface actually is
Ross Boylan writes:
> In Debian 11/bullseye my system keeps reporting timeouts while trying
> to bring up the first non-loopback interface.
I wonder why it is that you have a script for wpa_supplicant if you
don't have wireless interfaces?
Assuming that's not the problem, I guess you'll need to
On 27/8/22 6:06 am, Ross Boylan wrote:
In Debian 11/bullseye my system keeps reporting timeouts while trying
to bring up the first non-loopback interface. According to ip, the
interface actually is up, but ifup/down do not know that. My 2nd
interface is down, and there is no mention of attempt
Ross Boylan composed on 2022-08-26 15:06 (UTC-0700):
> I'd appreciate any suggestions about how to diagnose or cure the problem.
I switched most of my static installations to systemd-networkd.service last
year:
# inxi -Snz
System:
Kernel: 5.10.0-17-amd64 arch: x86_64 bits: 64 Console: pty pts/
On Fri, Aug 26, 2022 at 03:06:24PM -0700, Ross Boylan wrote:
> In Debian 11/bullseye my system keeps reporting timeouts while trying
> to bring up the first non-loopback interface. According to ip, the
> interface actually is up, but ifup/down do not know that. My 2nd
> interface is down, and the
if-up.d
Aug 26 11:55:20 barley ifup[1680]: run-parts: executing
/etc/network/if-up.d/000resolvconf
Aug 26 11:56:18 barley systemd[1]: networking.service: start operation
timed out. Terminating.
Aug 26 11:56:18 barley ifup[1563]: Got signal Terminated, terminating...
Aug 26 11:56:18 barley ifup[15
22 matches
Mail list logo
