On 3/12/25 10:51 AM, Robert McBroom via users wrote:
On 3/10/25 4:20 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Mar 09, 2025 at 04:34:35PM -0400, Robert McBroom wrote:
On 3/9/25 2:06 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Mar 09, 2025 at 06:45:24PM +0100, Michal Schorm wrote:
Hi
On 3/10/25 4:20 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Mar 09, 2025 at 04:34:35PM -0400, Robert McBroom wrote:
On 3/9/25 2:06 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Mar 09, 2025 at 06:45:24PM +0100, Michal Schorm wrote:
Hi,
this seems like a series of standalone issues caused
> On Mar 9, 2025, at 16:35, Robert McBroom via users
> wrote:
>> On 3/9/25 2:06 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>
>> Please show your /etc/group.
>
> That doesn't sound good to me that /etc/group should be rewritten willy
> nilly. Not sure about putting /etc/group in public.
Before
On 3/9/25 2:06 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Mar 09, 2025 at 06:45:24PM +0100, Michal Schorm wrote:
Hi,
this seems like a series of standalone issues caused by implementation
of this F42 Change:
https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers
Specificall
Hi,
this seems like a series of standalone issues caused by implementation
of this F42 Change:
https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers
Specifically for 'sphinx' it recently gained this commit:
https://src.fedoraproject.org/rpms/sphinx/c/7e51c472a?branch=rawhide
but
> On 28 Nov 2024, at 14:40, polak...@niif.hu wrote:
>
> This would make restarting less trouble because the system will *work* with
> the old configuration.
I do not think it will allow for this.
Better that you get into the habit of checking the config after any change you
make.
Otherwise a
> On 28 Nov 2024, at 14:40, polak...@niif.hu wrote:
>
> On the one hand, it is possible to check the configuration before starting,
> e.g. "sshd -t".
I am not sure what you expect this to help with.
If the config is bad the service will not start.
That is, I assume, exactly what having the s
For those, who tried to help me, big hand.
I think I found reason. OPENSSL.
I had to edit openssl.conf, to get TRUSTEDQSL work.
/etc/pki/tls/openssl.conf, There
# Uncomment the sections that start with ## below to enable the legacy provider.
# Loading the legacy provider enables support for the f
Sun, 10 Nov 2024 07:44:54 -0500
Jonathan Billings kirjoitti:
>> Sadly, your excerpt from the journal starts *just* after anything
> useful might have been recorded. It’s just systemd noise about the
> service not failing and how it isn’t restarting it.
>
> But I can’t comment further because ap
On Nov 10, 2024, at 03:04, jarmo wrote:
>
> I see no network, after starting computer, which I do very seldom,
> only when there comes kernel update.
> So network does not start at all and when doing journal query I get
> this, what I sent before...
>
> journalctl -xeu systemd-resolved.service
>
Sun, 10 Nov 2024 09:27:46 +
Barry kirjoitti:
> > On 10 Nov 2024, at 08:04, jarmo wrote:
> >
> > I see no network, after starting computer
>
> What does `ip addr` report when you have “no network”?
>
> I wonder if you have a hardware problem?
> Might be worth running memtest diagnostic t
> On 10 Nov 2024, at 08:04, jarmo wrote:
>
> I see no network, after starting computer
What does `ip addr` report when you have “no network”?
I wonder if you have a hardware problem?
Might be worth running memtest diagnostic to eliminate RAM issues.
Barry
--
__
Fri, 8 Nov 2024 23:14:57 +
Barry kirjoitti:
> > On 8 Nov 2024, at 13:19, jarmo wrote:
> >
> > Had to install inxi first :)
>
> Thanks for the info.
>
> Do you see systemd-resolved failing immediately after you first login?
> Or does if fail after you have been using the system for a lit
> On 8 Nov 2024, at 13:19, jarmo wrote:
>
> Had to install inxi first :)
Thanks for the info.
Do you see systemd-resolved failing immediately after you first login?
Or does if fail after you have been using the system for a little while?
After it fails do you see any journal logs about the oo
On Fri, 2024-11-08 at 01:19 -0500, Jeffrey Walton wrote:
> Disabling a service only lasts until the next (re)boot. And it does
> not stop currently executing services, and the service can still be
> started in the current session.
Not quite the full picture, not in general, even if that was a spec
Fri, 8 Nov 2024 12:58:16 +
Barry Scott kirjoitti:
>
> I asked for `inxi -Fzxx` that will provide a lot of info beyond RAM
> can you provide that?
>
> FYI I use `free -h` so that the numbers are easier to read.
>
> Barry
Had to install inxi first :)
Below is with systemd-resolved
System:
> On 8 Nov 2024, at 09:44, jarmo wrote:
>
> Fri, 8 Nov 2024 09:06:46 +
> Barry kirjoitti:
>
>>> On 8 Nov 2024, at 06:02, jarmo wrote:
>>>
>>> Process: 19413 ExecStart=/usr/lib/systemd/systemd-resolved
>>> (code=exited, status=1/FAILURE) Main PID: 19413 (code=exited,
>>> status=1/FAILURE
Fri, 8 Nov 2024 09:06:46 +
Barry kirjoitti:
> > On 8 Nov 2024, at 06:02, jarmo wrote:
> >
> > Process: 19413 ExecStart=/usr/lib/systemd/systemd-resolved
> > (code=exited, status=1/FAILURE) Main PID: 19413 (code=exited,
> > status=1/FAILURE) Error: 12 (Muistin varaaminen ei onnistu)
>
> T
> On 8 Nov 2024, at 06:02, jarmo wrote:
>
> Process: 19413 ExecStart=/usr/lib/systemd/systemd-resolved (code=exited,
> status=1/FAILURE)
> Main PID: 19413 (code=exited, status=1/FAILURE)
> Error: 12 (Muistin varaaminen ei onnistu)
This is ENOMEM and that implies your do not have enough
Fri, 8 Nov 2024 01:19:34 -0500
Jeffrey Walton kirjoitti:
get my network working.
>
> Disabling a service only lasts until the next (re)boot. And it does
> not stop currently executing services, and the service can still be
> started in the current session.
>
> If you want to permanently disa
On Fri, Nov 8, 2024 at 1:02 AM jarmo wrote:
> [...]
>
> So, I disable systemd-resolved and manually create /etc/resolv.conf
> to get my network working.
Disabling a service only lasts until the next (re)boot. And it does
not stop currently executing services, and the service can still be
started
Thu, 7 Nov 2024 22:10:31 +
Barry kirjoitti:
> > On 7 Nov 2024, at 17:31, Barry wrote:
> >
> > What is the output of systemctl status systemd-networkd?
>
> Sorry i mean the output of systemctl status systemd-resolved !
>
> Barry
>
systemctl status systemd-resolved
× systemd-resolved.se
> On 7 Nov 2024, at 17:31, Barry wrote:
>
> What is the output of systemctl status systemd-networkd?
Sorry i mean the output of systemctl status systemd-resolved !
Barry
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe sen
> On 7 Nov 2024, at 15:08, jarmo wrote:
>
> Won't start, claims something about memory,
> sorry, can't specify, made local resolv.conf
> to get network running..
What is the output of systemctl status systemd-networkd?
>
> It is enabled by default, I disabled to get
> self edited dns query
On 10/29/24 14:10, ToddAndMargo via users wrote:
On 10/29/24 14:01, ToddAndMargo via users wrote:
Hi All,
Fedora 39
Which should I have?
systemd-standalone-sysusers or systemd?
Just checked my Xfce Live USB. It is systemd
Cancel the request. It is an issue with lightdm. I replace
it
On 10/29/24 17:27, ToddAndMargo via users wrote:
Hi All,
Fedora 39
systemd-254.19-1.fc39.x86_64 (provides systemd-sysusers)
I can not get lightdm to start Xfc or MATE. After
entering my password into the greeter, I get a black
screen with a mouse pointer, then back to the greeter.
When I star
On 10/29/24 14:01, ToddAndMargo via users wrote:
Hi All,
Fedora 39
Which should I have?
systemd-standalone-sysusers or systemd?
Just checked my Xfce Live USB. It is systemd
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscrib
> On 16 Sep 2024, at 19:51, Robert McBroom via users
> wrote:
>
> As more and more things get fed into systemd, is there a resource to
> actually follow using it?
You mean documentation?
There are the man pages that are a good reference.
If you start with the this one
https://www.man7.org
> On 12 Apr 2024, at 05:42, Mike Wright wrote:
>
> Reason is because .socket files will activate their corresponding service
> files REGARDLESS of masking or disabling.
A masked service cannot do anything as masking replaced it with /dev/null.
Barry
--
__
> On 11 Apr 2024, at 12:59, Sam Varshavchik wrote:
>
> What I do see, though, is that we have both NetworkManager-wait-online and
> systemd-networkd-wait-online. Why do we need both of them?
It's odd that both are enabled.
On my kde plasma Vm only NetworkManager-wait-online.service is enable
On 4/11/24 15:08, Jeffrey Walton wrote:
On Thu, Apr 11, 2024 at 6:01 PM Sam Varshavchik wrote:
Tim via users writes:
"The service systemd-networkd-wait-online.service invokes systemd-
networkd-wait-online without any options. Thus, it waits for all
managed interfaces to be configured or fail
On Thu, Apr 11, 2024 at 6:01 PM Sam Varshavchik wrote:
>
> Tim via users writes:
>
> > "The service systemd-networkd-wait-online.service invokes systemd-
> > networkd-wait-online without any options. Thus, it waits for all
> > managed interfaces to be configured or failed, and for at least one to
Tim via users writes:
"The service systemd-networkd-wait-online.service invokes systemd-
networkd-wait-online without any options. Thus, it waits for all
managed interfaces to be configured or failed, and for at least one to
be online."
Could it be that you have some additional interfaces conf
On Thu, 2024-04-11 at 07:59 -0400, Sam Varshavchik wrote:
> What I do see, though, is that we have both NetworkManager-wait-
> online and systemd-networkd-wait-online. Why do we need both of them?
>
> I simply disabled systemd-networkd-wait-online, and that seems to
> solve the problem. NetworkMan
Roger Heflin writes:
Run this:
systemd-analyze critical-chain network-online.target
Can you explain why you think inspecting dependencies and starting times of
different systemd units would have any bearing on why a single unit, systemd-
network, is blowing chunks? Wasn't it clear from my e
Run this:
systemd-analyze critical-chain network-online.target
On Wed, Apr 10, 2024 at 6:20 AM Sam Varshavchik wrote:
>
> Samuel Sieb writes:
>
> > I have a similar problem where the wait-online service suddenly started
> > taking a very long time and then failing. My system that used to boot i
Samuel Sieb writes:
I have a similar problem where the wait-online service suddenly started
taking a very long time and then failing. My system that used to boot in a
few seconds now takes over a minute. So I have two questions.
What is it waiting for? My main ethernet card gets an addre
Tim via users writes:
On Tue, 2024-04-09 at 22:12 -0400, Sam Varshavchik wrote:
>
> Everything comes up normally. Network connectivity on this box is normal.
> Originally I was looking into why it took a long time for keepalived to
come
> up on this box and grab its virtual IP address, and I
On Tue, 2024-04-09 at 23:20 -0700, Samuel Sieb wrote:
> Perhaps more importantly, why can't that happen in the background? Why
> does gdm care if the network is connected?
It'd need to be *if* people are using a network share for their
homespace, or other "expected to be there" directories.
And
On 4/9/24 19:12, Sam Varshavchik wrote:
I've been made aware that it takes two minutes for
systemd-networkd-wait-online.service to spin its wheels, before giving
up with a squeal:
Apr 09 22:03:30 shorty.email-scan.com systemd[1]: Starting
systemd-networkd-wait-online.service - Wait for Networ
On Tue, 2024-04-09 at 22:12 -0400, Sam Varshavchik wrote:
> I've been made aware that it takes two minutes for systemd-networkd-wait-
> online.service to spin its wheels, before giving up with a squeal:
>
> Apr 09 22:03:30 shorty.email-scan.com systemd[1]: Starting
> systemd-networkd-wait-online
On 4/30/23 14:25, Jonathan Ryshpan wrote:
Here is an extract from the system log (a fuller extract is attached):
Mar 18 07:57:56 OaklandWeather.localdomain systemd[1]: Started
noip-duc.service - No-IP Dynamic Update Client.
Mar 18 07:57:58 OaklandWeather.localdomain systemd[1]: noip-duc.service:
On Mon, 1 May 2023 18:23:08 -0500
Roger Heflin wrote:
> I have something like this in my rc.local for similar reasons.
> ( sleep 30 ; cd /someplace ; ) &
I'm surprised that works. I used to have that sort of thing
directly in rc.local, then they converted the code that runs
rc.local to a systemd
I have something like this in my rc.local for similar reasons.
( sleep 30 ; cd /someplace ; ) &
On Mon, May 1, 2023 at 4:41 PM Tom Horsley wrote:
>
> On Mon, 01 May 2023 13:39:29 -0700
> Jonathan Ryshpan wrote:
>
> > And the problem remains. Further advice would be welcome.
>
> Without ever mana
> On 1 May 2023, at 22:41, Tom Horsley wrote:
>
> On Mon, 01 May 2023 13:39:29 -0700
> Jonathan Ryshpan wrote:
>
>> And the problem remains. Further advice would be welcome.
>
> Without ever managing to determine what the problem was, I have
> sometimes resorted to disabling the service, the
On Mon, 01 May 2023 13:39:29 -0700
Jonathan Ryshpan wrote:
> And the problem remains. Further advice would be welcome.
Without ever managing to determine what the problem was, I have
sometimes resorted to disabling the service, then making an
rc.local script that uses the "at" command to start th
On Sun, 2023-04-30 at 16:41 -0500, Chris Adams wrote:
> Once upon a time, Jonathan Ryshpan said:
> > This unit
> > $ cat /etc/systemd/system/noip-duc.service
> > [Unit]
> > Description=No-IP Dynamic Update Client
> > After=network.target auditd.service
>
> This should probably be n
Once upon a time, Jonathan Ryshpan said:
> This unit
>$ cat /etc/systemd/system/noip-duc.service
>[Unit]
>Description=No-IP Dynamic Update Client
>After=network.target auditd.service
This should probably be network-online.target.
> always fails at boot time with the message st
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2177722 for my original
problem (involving non-DE logins) and it was indeed fixed with the latest
systemd updates in both F37 and F38. I know other people have reported it
happening in GNOME but have never seen it personally. There are closed b
On Sun, 12 Mar 2023 13:37:46 -, Andre Robatino wrote:
> I have 3 machines with clean F37 installs.
Dunno yet whether it's also F37 or just F38, but here on F38 even
gnome-terminal is getting killed when running a simple tar command in it
that works on creating a ~20 GB archive.
__
Thanks. I confirmed on the affected machine that immediately after removing
systemd-oomd-defaults, it was still monitoring the same CGroups, but after
rebooting, it was monitoring none, even though systemd-oomd was still enabled
and running.
___
users
Hi.
On Sun, 12 Mar 2023 17:33:42 + "Andre Robatino" wrote:
> I just tried removing systemd-oomd-defaults and it's still possible to run
> systemd-oomd so I was wrong in thinking that would prevent it.
Right: systemd-oomd-defaults only configures systemd-oomd.
rpm -ql --scripts systemd-
I've heard that, but for me, with limited RAM, both DNF transactions and an
rsync of a very large file fail in multiuser (by causing logout while they're
running) while they both succeed in GNOME on the same machine.
___
users mailing list -- users@list
Andre Robatino composed on 2023-03-12 15:58 (UTC):
> BTW, I did notice that the problem was gone during the time that systemd-oomd
> wasn't running, so that's definitely the cause. Unfortunately, the mask
> command alone isn't enough to prevent it from running, I'd have to either
> remove syste
I just tried removing systemd-oomd-defaults and it's still possible to run
systemd-oomd so I was wrong in thinking that would prevent it.
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproj
On Sun, Mar 12, 2023 at 9:38 AM Andre Robatino
wrote:
>
> I have 3 machines with clean F37 installs. One of the F37 machines has 4GB of
> RAM, and I maintain it as a backup and normally only log in via ssh and do
> dnf updates via command line. In the last few weeks this has become extremely
>
On Sun, 12 Mar 2023 15:47:48 -
"Andre Robatino" wrote:
> Does your machine have 4GB or less of RAM? If you have more, it may
> be much less likely to trigger. I just verified that when I log into
Yeah, 16 GB.
> GNOME on the machine in question, an rsync of a single large file
> that never w
I've heard dnf uses a lot of memory, but in my 2GB F38 VM, I can run a large
DNF transaction with no problem when logged into GNOME. On 4GB F37 bare metal,
in multiuser, even updating one letter at a time isn't enough, even "dnf check"
can fail. I read somewhere that GNOME and KDE are the only t
> On 12 Mar 2023, at 15:58, Andre Robatino wrote:
>
> BTW, I did notice that the problem was gone during the time that
> systemd-oomd wasn't running, so that's definitely the cause. Unfortunately,
> the mask command alone isn't enough to prevent it from running, I'd have to
> either remove
BTW, I did notice that the problem was gone during the time that systemd-oomd
wasn't running, so that's definitely the cause. Unfortunately, the mask command
alone isn't enough to prevent it from running, I'd have to either remove
systemd-oomd-defaults or edit some config files. And this really
Does your machine have 4GB or less of RAM? If you have more, it may be much
less likely to trigger. I just verified that when I log into GNOME on the
machine in question, an rsync of a single large file that never works when done
remotely works fine, it only fails when attempted from a non-DE lo
On Sun, 12 Mar 2023 13:37:46 -
"Andre Robatino" wrote:
> I have 3 machines with clean F37 installs. One of the F37 machines
> has 4GB of RAM, and I maintain it as a backup and normally only log
> in via ssh and do dnf updates via command line. In the last few weeks
> this has become extremely
It's not just ssh. It happens even if I boot in multiuser and log in via the
console, so any non-DE login is affected. Sometimes, I can't even run a simple
"dnf check" command (after having a previous transaction aborted by a logout)
without being logged out again. And the free command indicates
On Sun, Mar 12, 2023 at 10:38 AM Andre Robatino
wrote:
> I have 3 machines with clean F37 installs. One of the F37 machines has 4GB
> of RAM, and I maintain it as a backup and normally only log in via ssh and
> do dnf updates via command line. In the last few weeks this has become
> extremely dif
On 2/23/23 09:19, Jonathan Billings wrote:
On Feb 23, 2023, at 08:45, Robert Nichols wrote:
If I want to use a tmpfs for /tmp, I can just enable the systemd tmp.mount
unit and get the default size limit of 1/2 of memory. If I want to reduce that
limit, I either have to fiddle with a systemd
On Feb 23, 2023, at 08:45, Robert Nichols wrote:
>
> If I want to use a tmpfs for /tmp, I can just enable the systemd tmp.mount
> unit and get the default size limit of 1/2 of memory. If I want to reduce
> that limit, I either have to fiddle with a systemd override or else put a
> line in /et
> On 5 Aug 2022, at 12:27, Richard W.M. Jones wrote:
>
> On Fri, Aug 05, 2022 at 12:16:46PM +0100, Richard W.M. Jones wrote:
>> I think this is a systemd bug.
>
> It seems like the source/sink check was added recently to fix:
>
> https://github.com/systemd/systemd/issues/21988
>
> but that
On Fri, Aug 05, 2022 at 12:16:46PM +0100, Richard W.M. Jones wrote:
> I think this is a systemd bug.
It seems like the source/sink check was added recently to fix:
https://github.com/systemd/systemd/issues/21988
but that the fix is either wrong or incomplete.
Here's another interesting related
On Fri, Aug 05, 2022 at 11:36:13AM +0100, Barry wrote:
>
>
> > On 5 Aug 2022, at 10:48, Richard W.M. Jones wrote:
> >
> > Fedora 36, plocate-1.1.15-3.fc36.x86_64, systemd-250.8-1.fc36.x86_64
> >
> > /usr/lib/systemd/system/plocate-updatedb.service has
> > ConditionACPower=true because they do
> On 5 Aug 2022, at 10:48, Richard W.M. Jones wrote:
>
> Fedora 36, plocate-1.1.15-3.fc36.x86_64, systemd-250.8-1.fc36.x86_64
>
> /usr/lib/systemd/system/plocate-updatedb.service has
> ConditionACPower=true because they don't want updatedb to run
> when on a laptop battery.
>
> Now, my machi
On Sat, 2022-04-16 at 13:51 +, Mark Levis wrote:
> Nice
What's nice?
poc
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.
Nice
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.
Hi,
> There used to be a timer similar to something like
> amavis-quarantine-clean.timer that periodically would remove old files
> from /var/spool/amavisd/quarantine, but it's nowhere on the system on
> fedora35, yet the system is somehow deleting files older than 30 days
> from the quarantine st
On Feb 10, 2022, at 18:55, Alex wrote:
>
> There used to be a timer similar to something like
> amavis-quarantine-clean.timer that periodically would remove old files
> from /var/spool/amavisd/quarantine, but it's nowhere on the system on
> fedora35, yet the system is somehow deleting files older
Hi,
> > There used to be a timer similar to something like
> > amavis-quarantine-clean.timer that periodically would remove old files
> > from /var/spool/amavisd/quarantine, but it's nowhere on the system on
> > fedora35, yet the system is somehow deleting files older than 30 days
> > from the qua
> On 10 Feb 2022, at 23:55, Alex wrote:
>
> Hi,
> There used to be a timer similar to something like
> amavis-quarantine-clean.timer that periodically would remove old files
> from /var/spool/amavisd/quarantine, but it's nowhere on the system on
> fedora35, yet the system is somehow deleting fi
On 14/04/2021 02:38, Jack Craig wrote:
On Tue, Apr 13, 2021 at 3:52 AM Tim via users mailto:users@lists.fedoraproject.org>> wrote:
On Mon, 2021-04-12 at 12:06 -0700, Jack Craig wrote:
> Oh so now I have learned something new.
>
> I thought that because I was a Domain owner, I had
On Tue, Apr 13, 2021 at 3:52 AM Tim via users
wrote:
> On Mon, 2021-04-12 at 12:06 -0700, Jack Craig wrote:
> > Oh so now I have learned something new.
> >
> > I thought that because I was a Domain owner, I had to do the
> > translation from my public IP to my local DNS name
>
> Just to be clear:
On Mon, Apr 12, 2021 at 11:54 PM J.Witvliet--- via users <
users@lists.fedoraproject.org> wrote:
>
>
>
> *From: *"Jack Craig"
> *Date:* Monday, 12 April 2021 at 21:07:07
> *To: *"Community support for Fedora users"
> *Subject:* Re: systemd-resolv
On 13/04/2021 18:52, Tim via users wrote:
You can see that sort of thing with the "dig" tool. If you do a "dig
example.com" you'll get a collection of responses. The "answer"
section is the domain name and numerical IP address for it, that you
queried. The "authority" section will be the autho
On Mon, 2021-04-12 at 12:06 -0700, Jack Craig wrote:
> Oh so now I have learned something new.
>
> I thought that because I was a Domain owner, I had to do the
> translation from my public IP to my local DNS name
Just to be clear:
By "your public IP" do mean the IP for your server that the worl
From: "Jack Craig"
mailto:jack.craig.ap...@gmail.com>>
Date: Monday, 12 April 2021 at 21:07:07
To: "Community support for Fedora users"
mailto:users@lists.fedoraproject.org>>
Subject: Re: systemd-resolved, split dns, & vpn setup
Oh so now I have learned so
Oh so now I have learned something new.
I thought that because I was a Domain owner, I had to do the translation
from my public IP to my local DNS name
in as much as networksolutions.com, my domain registrar provider, has
already the IP and host name then
I don't need to provide that so let me t
I'm answering this with a separate response because it goes off in a
different direction. You can decide which way to go without mixing up
all the information together.
On Sat, 2021-04-10 at 12:03 -0700, Jack Craig wrote:
> I think I understand that the primary name server for domain must be
> in
On Sat, 2021-04-10 at 12:03 -0700, Jack Craig wrote:
> OK time to share the real problem here ,it is me. that is to say
> after several decades of computer work I got Parkinson's and that
> forced me to stop working commercially. I didn't want to give up my
> networking all the way so I keep thi
On Sat, Apr 10, 2021 at 1:20 AM Tim via users
wrote:
> On Thu, 2021-04-08 at 13:37 -0700, Jack Craig wrote:
> > I have tried at length to get bind 9 to support proper a split
> > horizon configuration without success.
>
> I remember going through that with you last year. It definitely works,
> a
On Thu, 2021-04-08 at 13:37 -0700, Jack Craig wrote:
> I have tried at length to get bind 9 to support proper a split
> horizon configuration without success.
I remember going through that with you last year. It definitely works,
as I did it on my system as I went through it with you.
Do you hav
hi Peter,
thx very much for your time & expertise.
very much appreciated, jackc...
On Thu, Apr 8, 2021 at 4:11 PM Peter Boy wrote:
>
>
> > Am 08.04.2021 um 22:37 schrieb Jack Craig :
> >
> > This was looking like a good solution until I got down to the end of the
> second article
> > where it
> Am 08.04.2021 um 22:37 schrieb Jack Craig :
>
> This was looking like a good solution until I got down to the end of the
> second article
> where it said, if I understand this correctly, the systemD-resolveD is not
> appropriate for the primary DNS server of a domain.
Indeed, systems-reso
On 11/01/2021 03:25, Jerome Lille wrote:
On Sun, 2021-01-10 at 15:44 +0800, Ed Greshko wrote:
On 06/01/2021 00:10, Jerome Lille wrote:
I've just updated a desktop from Fedora 32 to 33 and after that the
logs are flooded with the following message
systemd-resolved[]: Using degraded feature set
On Sun, 2021-01-10 at 15:44 +0800, Ed Greshko wrote:
> On 06/01/2021 00:10, Jerome Lille wrote:
> > I've just updated a desktop from Fedora 32 to 33 and after that the
> > logs are flooded with the following message
> >
> > systemd-resolved[]: Using degraded feature set TCP instead of UDP
> > for
Ed Greshko writes:
Networkmanager must be checking if /etc/resolv.conf is a symbolic link and
only updating its own private resolver configs, otherwise it'll update them
and /etc/resolv.conf
I have no idea of what "private configs" you speak. I also can't think of
The configs in /var/run
On 10/01/2021 14:50, Ed Greshko wrote:
I also can't think of why NM would ever check if
/etc/resolv.conf was a symlink.
I actually meant to say there would be no need to check if systemd-resolved is
masked.
But, either way, that was not a very well thought out statement.
---
The key to gettin
On 06/01/2021 00:10, Jerome Lille wrote:
I've just updated a desktop from Fedora 32 to 33 and after that the
logs are flooded with the following message
systemd-resolved[]: Using degraded feature set TCP instead of UDP for
DNS server 127.0.0.1.
systemd-resolved[]: Using degraded feature set UDP
On 10/01/2021 11:04, Tim via users wrote:
Ed Greshko:
When I tested reverting to the previous behavior I simply started
with an empty /etc/resolv.conf.
No symlink. No selinux troubles. Everything just worked.
Sam Varshavchik:
Well, then how do the apps that need to talk to the DNS server fin
On 10/01/2021 12:24, Sam Varshavchik wrote:
Tim via users writes:
Ed Greshko:
>> When I tested reverting to the previous behavior I simply started
>> with an empty /etc/resolv.conf.
>> No symlink. No selinux troubles. Everything just worked.
Sam Varshavchik:
> Well, then how do the apps that
Tim via users writes:
Ed Greshko:
>> When I tested reverting to the previous behavior I simply started
>> with an empty /etc/resolv.conf.
>> No symlink. No selinux troubles. Everything just worked.
Sam Varshavchik:
> Well, then how do the apps that need to talk to the DNS server find
> it? M
Ed Greshko:
>> When I tested reverting to the previous behavior I simply started
>> with an empty /etc/resolv.conf.
>> No symlink. No selinux troubles. Everything just worked.
Sam Varshavchik:
> Well, then how do the apps that need to talk to the DNS server find
> it? Maybe something in the gli
Ed Greshko writes:
When I tested reverting to the previous behavior I simply started with an
empty /etc/resolv.conf.
No symlink. No selinux troubles. Everything just worked.
Well, then how do the apps that need to talk to the DNS server find it?
Maybe something in the glibc resolver know
On 10/01/2021 09:17, Ed Greshko wrote:
On 10/01/2021 09:12, Sam Varshavchik wrote:
Doug H. writes:
>
> Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to
> be fixed.
Thanks for opening that bug.
Note that my outbound e-mail was being blocked by this. I am using post
1 - 100 of 442 matches
Mail list logo
