Re: ntpsec as server questions

[Jeffrey Walton]

On Mon, Dec 4, 2023 at 1:23 AM Charles Curley
 wrote:
>
> On Mon, 4 Dec 2023 00:20:45 -0500
> Jeffrey Walton  wrote:
>
> > I'm not sure that is correct. According to RFC 2132, Section 8.3, the
> > NTP time server source option is IP addresses, not hostnames. That
> > means ISC DHCP docs need to say it resolves a hostname to an IP, or it
> > needs to tell people to use IP addresses in accordance with the RFC.
> > See .
>
> Well, I don't know about the RFC, but the ISC DHCP server gets along
> find with host names. From my /etc/dhcp/dhcpd.conf:
>
> option ntp-servers ntp.localdomain, ntp1.localdomain;  # issola, aliased; 
> chaffee, aliased.
>
> I think the server looks the addresses up and transmits the addresses.
> My clients see IP addresses, anyway.
>
> > If you try that [using a hostname in NTP server option] with the ISC's
> > KEA DHCP (KEA is ISC's rewrite of the old DHCP server), then the
> > server fails to start. You must use an IP address for NTP server
> > option with KEA DHCP.
>
> Well, that's silly. One of the nice things about using host names is
> that you can move the service from one machine to another (as I just
> did) and all you have to do is change the alias in your zone file.
>
> I'm not going to look to see if a more recent RFC amends that.

Well, I don't disagree with you:
.
It makes sense that a hostname is resolved since it could reveal a
pool of NTP servers. And then the server could send the IP addresses
associated with the pool. But what do I know...

Jeff

Re: ntpsec as server questions

[Charles Curley]

On Mon, 4 Dec 2023 00:20:45 -0500
Jeffrey Walton  wrote:

> I'm not sure that is correct. According to RFC 2132, Section 8.3, the
> NTP time server source option is IP addresses, not hostnames. That
> means ISC DHCP docs need to say it resolves a hostname to an IP, or it
> needs to tell people to use IP addresses in accordance with the RFC.
> See .

Well, I don't know about the RFC, but the ISC DHCP server gets along
find with host names. From my /etc/dhcp/dhcpd.conf:

option ntp-servers ntp.localdomain, ntp1.localdomain;  # issola, aliased; 
chaffee, aliased.

I think the server looks the addresses up and transmits the addresses.
My clients see IP addresses, anyway.

> 
> If you try that [using a hostname in NTP server option] with the ISC's
> KEA DHCP (KEA is ISC's rewrite of the old DHCP server), then the
> server fails to start. You must use an IP address for NTP server
> option with KEA DHCP.

Well, that's silly. One of the nice things about using host names is
that you can move the service from one machine to another (as I just
did) and all you have to do is change the alias in your zone file.

I'm not going to look to see if a more recent RFC amends that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: DHCP Problem

[Charles Curley]

On Mon, 4 Dec 2023 05:55:50 +0100
 wrote:

> Wait a sec: before the clients get an answer from the DHCP server,
> they don't have any route (at least not for the network in question),
> so it doesn't make sense poking at them with ip route and things.
> They send their request to the local network's segment broadcast
> address.

As I understand things, that's true of the first request a client
makes, say, at boot. After that, the client knows which machine it got
its last lease from and can query directly.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: ntpsec as server questions

[Jeffrey Walton]

On Mon, Dec 4, 2023 at 12:09 AM  wrote:
>
> On Sun, Dec 03, 2023 at 07:42:42PM -0500, gene heskett wrote:
> > Greetings all;
> >
> > in the docs (thanks for hiding them & doing away with manpages) it says:
> > ---
> > To make the DHCP server in the Debian package isc-dhcp-server send NTP
> > server
> > information, add a line like the following at an appropriate place:
> >
> > option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
> > --
> > now I assume the foo.bar is to be replaced by something unique [...]
>
> The whole thing is supposed to be a resolvable host name for your client,
> i.e. either something your client can look up in the DNS, something in
> its /etc/hosts, possibly even a naked IP address will do. It's quite
> likely the request goes through the resolver (which, BTW, has a man page).

I'm not sure that is correct. According to RFC 2132, Section 8.3, the
NTP time server source option is IP addresses, not hostnames. That
means ISC DHCP docs need to say it resolves a hostname to an IP, or it
needs to tell people to use IP addresses in accordance with the RFC.
See .

If you try that [using a hostname in NTP server option] with the ISC's
KEA DHCP (KEA is ISC's rewrite of the old DHCP server), then the
server fails to start. You must use an IP address for NTP server
option with KEA DHCP.

Jeff

Re: ntpsec as server questions

[tomas]

On Sun, Dec 03, 2023 at 07:42:42PM -0500, gene heskett wrote:
> Greetings all;
> 
> in the docs (thanks for hiding them & doing away with manpages) it says:
> ---
> To make the DHCP server in the Debian package isc-dhcp-server send NTP
> server
> information, add a line like the following at an appropriate place:
> 
> option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
> --
> now I assume the foo.bar is to be replaced by something unique [...]

The whole thing is supposed to be a resolvable host name for your client,
i.e. either something your client can look up in the DNS, something in
its /etc/hosts, possibly even a naked IP address will do. It's quite
likely the request goes through the resolver (which, BTW, has a man page).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: DHCP Problem

[tomas]

On Sun, Dec 03, 2023 at 12:30:53PM -0700, Charles Curley wrote:
> I am installing a new router which seems to work well so far.
> 
> I have changed the DHCP server to use the new router's address, and shut
> the server down and restarted it. Existing clients insist on using the
> old router anyway. Is there any way to goose clients into using the new
> one short of manually using the ip route command?

Wait a sec: before the clients get an answer from the DHCP server, they
don't have any route (at least not for the network in question), so it
doesn't make sense poking at them with ip route and things. They send their
request to the local network's segment broadcast address.

What's possibly happening is that your old DCHP server is still up and
running and faster than your new one, so its answers come in first.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: time question, as in ntp?

[John Hasler]

Max Nikulin wrote:
> From my point of view, it should be possible to put a file with
> mapping of mac addresses to desired IPs and names to his dd-wrt
> router. I expect that dnsmasq is running or can be installed
> there. Dnsmasq as a DHCP server on the router should be better than
> maintaining hosts files on each machine.

dnsmasq will get the hostnames from the machines and put them in its
dns.  There is really no need to manually enter any MAC addresses or IPs
anywhere.

I suspect that had the machine been plugged into a network equipped with
a properly configured DHCP server it would just work.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: DHCP Problem, but where

[Charles Curley]

On Sun, 3 Dec 2023 22:32:59 -0500
Jeffrey Walton  wrote:

> The "restart your dhcp clients" may have a sharp edge. Sometimes the
> clients have a touch of resiliency or hardening added so they contact
> their original dhcp server, and not a [possibly] rogue server setup by
> an unknowing developer or attacker. In the past, you used to have to
> reboot Microsoft clients to get them to use the new dhcp server. I
> don't know Linux behavior.
> 
> But if the problem is, dhcp clients are using the old dhcp server or
> old dhcp lease info, then I would try to reboot a client if the
> service restart did not help.

I think the ISC dhclient (which is what I use here) does try to return
to its original server. Rather than reboot anything, I simply stopped
the DHCP server on that machine. Apparently clients then started back at
the beginning. Shortening the lease time accelerates that process.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: DHCP Problem

[Charles Curley]

On Sun, 3 Dec 2023 12:30:53 -0700
Charles Curley  wrote:

> I am installing a new router which seems to work well so far.
> 
> I have changed the DHCP server to use the new router's address, and
> shut the server down and restarted it. Existing clients insist on
> using the old router anyway. Is there any way to goose clients into
> using the new one short of manually using the ip route command?
> 
> 

OK, stupid mistake of the week.

The frustrating problem was that the clients kept getting the old
router's IP address. This was for the simple reason that I had managed
to not change the value of the "option routers" entry for the subnet.
Doh! I have fixed that. Never be afraid to recheck your own work.

I did shorten the lease times and that has accelerated the changeover.
I didn't need to restart all the client's leases. Two days hence I'll
change them back.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: DHCP Problem, but where

[Jeffrey Walton]

On Sun, Dec 3, 2023 at 9:57 PM jeremy ardley  wrote:
>
>
> On 4/12/23 05:18, Geert Stappers wrote:
> > That triggered me to ask "Has the DHCP server been restarted?"
>
>
> The default behaviour of most dhcp clients when they can't connect to a
> dhcp server is to maintain the settings from any previous lease.
>
> A second default behaviour is for clients to not request new dhcp until
> their existing dhcp lease has expired.
>
> To make sure a new dhcp setting is taken by all clients you need to
>
> -  reconfigure your dhcp server
>
> - restart your dhcp server
>
> - check your dhcp server logs for any problems
>
> - restart your dhcp clients
>
> - check your client dhcp logs to see if the new lease info has been taken.
>
> There can be problems where a client with a specific MAC address
> requests a specific ip address based on a previous lease but the server
> is unwilling or unable to allocate that address to that MAC. This can be
> checked in the server and client logs. It may also require flushing the
> server lease tables and client configs so they can both start out
> completely fresh.

The "restart your dhcp clients" may have a sharp edge. Sometimes the
clients have a touch of resiliency or hardening added so they contact
their original dhcp server, and not a [possibly] rogue server setup by
an unknowing developer or attacker. In the past, you used to have to
reboot Microsoft clients to get them to use the new dhcp server. I
don't know Linux behavior.

But if the problem is, dhcp clients are using the old dhcp server or
old dhcp lease info, then I would try to reboot a client if the
service restart did not help.

(I saw a similar attack happen as an undergrad at the University of
Maryland. Someone in the CS department setup a Linux server with
Kerberos running. Workstations got answers from the rogue server and
got [useless] tickets granted, and the [useless] tickets could not be
used for authenticating to other services on the UMBC network. It was
an intermittent problem, and it took a couple of weeks to straighten
it out).

Jeff

Re: time question, as in ntp?

[Max Nikulin]

On 02/12/2023 23:39, John Hasler wrote:

Max Nikulin wrote:

As to a GPS receiver, it should be doable and 169.254.x.y addresses
will not be an issue any more. Be careful with cables when connecting
it however: https://www.wired.com/2012/02/neutrinos-faulty-cable/


CNC machines don't need accurate time.  They need precise internal
synchronization but that isn't related to the system clocks.  The
default NTP configuration in most Linux distributions will take care of
the system clocks if they have access to the Internet.


I was kidding. However "access to the Internet" is the real trouble in 
this particular case. It seems, the vendor of the 3d printer believes 
that users must connect the device to a network having a DHCP server. 
ifupdown is definitely broken in armbian, perhaps armbian way to setup 
network is broken on this device, but Gene is not going to debug it. His 
stance that it is NetworkManager that breaks his network.


In addition, he is strongly against DHCP believing that it will make his 
network unstable.


From my point of view, it should be possible to put a file with mapping 
of mac addresses to desired IPs and names to his dd-wrt router. I expect 
that dnsmasq is running or can be installed there. Dnsmasq as a DHCP 
server on the router should be better than maintaining hosts files on 
each machine.


The current state is that the 3d printer has only a 169.254.x.y 
link-local address configured as a fallback.

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 04/12/2023 09:39, jeremy ardley wrote:

I think I've found a potential culprit using about:processes

https://openai.com 110% CPU


I would try it in chromium. Some sites relies on optimizations 
implemented in its JavaScript engine.


My observation is that Firefox may be CPU hungry due to "loading" 
animations (CSS and others). Curiously it may happen namely when JS is 
disabled since otherwise animated placeholders are replaced by 
dynamically loaded content that is still.


I have also been monitoring global memory use. The last entry below is 
after I closed the openai tab


I have not used atop, but a colleague recommended it. This tool may 
write logs.

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 4/12/23 10:26, Max Nikulin wrote:
 > I am curious if this creature may provide a summary on user-space OOM 
> killers. I have never tried them, but I expect that they may be more 
> intelligent than the kernel-space one. I have seen mentions of the > 
following ones: earlyoom, nohang, oomd.


I think I've found a potential culprit using about:processes

https://openai.com 110% CPU

(That's GPT4)

Firefox at this time is running around 1GB memory

The super high CPU for openai is certainly a whole bunch of javascript. 
I closed that tab and the CPU load dropped to normal. Reloading the 
openai website and CPU oscillated between 1% and 20% till it settled 
around 1%


I have also been monitoring global memory use. The last entry below is 
after I closed the openai tab


root@client:~# date; free -m
Mon 04 Dec 2023 09:14:29 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   12400   10521 426 10136   19622
Swap:    976   8 968
root@client:~# date; free -m
Mon 04 Dec 2023 10:04:56 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   12913    9959 437 10197   19110
Swap:    976   8 968
root@client:~# date; free -m
Mon 04 Dec 2023 10:28:19 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   13113    9732 419 10206   18910
Swap:    976   8 968
root@client:~# date; free -m
Mon 04 Dec 2023 10:32:58 AWST
   total    used    free  shared buff/cache   
available

Mem:   32023   12545   10297 428 10217   19478
Swap:    976   8 968

This does not explain the OOM problem, but it seems memory is slowly 
being consumed at a rate where in 24 hours I'll start seeing problems again.

Re: Isolated Web Co Session crash Firefox-ESR

[Max Nikulin]

On 03/12/2023 13:33, jeremy ardley wrote:

On 3/12/23 13:59, Phil Wyett wrote:

What type of content is generally being viewed/used in firefox?


A lot of video and otherwise news and search and GPT4

---

I am curious if this creature may provide a summary on user-space OOM 
killers. I have never tried them, but I expect that they may be more 
intelligent than the kernel-space one. I have seen mentions of the 
following ones: earlyoom, nohang, oomd.


Do you have AI browser extensions that may load huge models in respect 
to memory footprint?


When the system starts to become sluggish, have you looked at the 
firefox 'Task Manager' under tools to see if anything stands out?


Previously I have seen the Isolated Web Co processes maxing CPU and the 
CPU fans starting to roar. Nothing unusual in content at the time and if 
I kill all ESR related processes it quiets down and I can resume the 
closed windows and tabs at much reduced CPU


It is just a process that is responsible for some web pages. JavaScript 
loaded for particular sites may leak. Videos may consume RAM as well. I 
would not rely too much on ability of an application to recover after 
killing of its specific processes. From my point of view it is better to 
restart Firefox in such cases.


Perhaps it is possible to find a particular site that causes issues, but 
you need to inspect system namely when it is becoming sluggish.


Firefox has the about:processes and about:performance tools. They may be 
accessed from the about:about list.


Try to sort top(1) output by memory ("M" key), try df(1) to check tmpfs 
usage for the case that enough temporary video files are stored there.


I believed that 32G of RAM is still above that "average" users have, so 
it should be enough. Other suggestions surprised me that 0.5G of swap 
may significantly change anything since it is less than 2% of RAM.

Re: Isolated Web Co Session crash Firefox-ESR

[Tom Dial]

On 12/3/23 01:00, jeremy ardley wrote:

On 3/12/23 15:37, Phil Wyett wrote:

Not to regurgitating info here, I will add a link below that will instruct how 
to adjust or disable oom-killer in a sensible manner if you wish to experiment 
(your choice and being cautious :-)) if it is in fact the oom-killer algorithm 
that is the main cause of your issue.



The top output provided earlier seems to show nearly a gigabyte of swap, a tiny 
part of it used. You are right, though, that adding swap will not improve 
matters for long.

A small amount of swap probably is a good idea to take care of occasional 
memory overcommitment. But on an interactive system, swap thrashing that may 
happen with a (or several) greedy enough processes will kill performance for 
everything that matters, and if one or more of them is leaking memory, adding 
swap (or even more memory) will only delay the collapse.

As a reference point Isolated Web Co is an occasional annoyance here on 
machines with well over 64G memory. I kill it without mercy when it appears to 
be causing swap.

Regards,
Tom Dial




The issue is not so much Isolated Web Co being terminated, but my entire Mate 
session being terminated.

I wouldn't have too much problem if OOM-killer hit Firefox. I have done it 
myself when things got slow.

However, I can't see any valid reason for the Mate session to be assassinated? 
Or at least be inevitable collateral damage.

Re: ntpsec as server questions

[jeremy ardley]

On 4/12/23 08:51, jeremy ardley wrote:
|ntpq -p timedatectl status chronyc sources or if you are hardcore 
sudo tcpdump -i any port 123 | 



Sorry, something screwed up the list

One or more of:

ntpq -p

timedatectl status

chronyc sources

or if you are hardcore

sudo tcpdump -i any port 123

Re: ntpsec as server questions

[jeremy ardley]

On 4/12/23 08:42, gene heskett wrote:


At the other end of the local wires and switches tree on my other 
machines, what is the list of debian.pool.ntp.org replaced with? 



To find out what ntp server(s) a system is using as compared to what may 
be in config files or set by dhcp client, try one or more of these:


|ntpq -p timedatectl status chronyc sources or if you are hardcore sudo 
tcpdump -i any port 123 |

Re: ntpsec as server questions

[Greg Wooledge]

On Sun, Dec 03, 2023 at 07:42:42PM -0500, gene heskett wrote:
> in the docs (thanks for hiding them & doing away with manpages) it says:
> ---
> To make the DHCP server in the Debian package isc-dhcp-server send NTP
> server
> information, add a line like the following at an appropriate place:
> 
> option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
> --

I have never once seen a host use NTP servers which were suggested by a
DHCP server.  I can't speak for others.

I would simply ignore that section, but if you feel like you want your
hosts to be told which NTP servers to use via DHCP, then you can try it.

ntpsec as server questions

[gene heskett]

Greetings all;

in the docs (thanks for hiding them & doing away with manpages) it says:
---
To make the DHCP server in the Debian package isc-dhcp-server send NTP 
server

information, add a line like the following at an appropriate place:

option ntp-servers ntp1.foo.bar, ntp2.foo.bar;
--
now I assume the foo.bar is to be replaced by something unique but 
probably referencing this system doing the serving. How would this be 
determined?  Also "appropriate place" needs better defined.


At the other end of the local wires and switches tree on my other 
machines, what is the list of debian.pool.ntp.org replaced with?


Thank you.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: goose DHCP clients to new address Was: DHCP Problem

[Charles Curley]

On Sun, 3 Dec 2023 17:18:23 -0500
Jeffrey Walton  wrote:

> I don't know about Linux clients, but in the past, Windows clients
> used to try to connect to the previous DHCP server for its lease info.
> If the old DHCP server is still available (on the old router?), then
> the client may be getting the lease info from the old server. To avoid
> the problem, we disconnected the old server from the network.

I did shut down both the old server and its failover peer. Clients I
haven't mucked with are now asking for leases from the new server.

Dec 03 14:55:48 issola dhcpd[24072]: failover peer failover-partner: I move 
from startup to communications-interrupted
Dec 03 15:09:46 issola dhcpd[24072]: DHCPREQUEST for 192.168.100.45 from 
ec:28:d3:7a:6a:76 via enp1s0
Dec 03 15:09:46 issola dhcpd[24072]: DHCPACK on 192.168.100.45 to 
ec:28:d3:7a:6a:76 via enp1s0
Dec 03 15:40:50 issola dhcpd[24072]: DHCPREQUEST for 192.168.100.45 from 
ec:28:d3:7a:6a:76 via enp1s0
Dec 03 15:40:50 issola dhcpd[24072]: DHCPACK on 192.168.100.45 to 
ec:28:d3:7a:6a:76 via enp1s0

But that guy is still pointing toward the old router.

> 
> You should probably just perform a hard cut-over. Shutdown the old
> router, stand up the new router. After the hard cutover, force clients
> to renew their leases (or wait until they do it on their own). And if
> things go sideways, undo the change.

I may yet do that. The change will consist of pulling the Ethernet cable
between the old router and its upstream connection.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 4/12/23 06:08, Michael Kjörling wrote:
The reason for the system slowing down seems to me to likely be that 
once the system comes under memory pressure (quite possibly due to an 
increase in anonymous pages), it must evict something, and only 
non-anonymous (that is, backed) pages can be evicted safely. So most 
likely the allocator starts evicting program code, because that can be 
read back from storage later, or other forms of cache, in order to 
keep room for the anonymous pages which it cannot evict. The next time 
that code is needed, it must go all the way to the (horribly slow by 
comparison) storage, instead of originally just writing out to swap 
some anonymous pages which haven't been used in comparatively forever, 
like a tmpfs that someone mentioned, or data for inactive web browser 
tabs or documents you aren't doing anything active with.



It turns out I actually do have a modest swap though I don't recall 
enabling it. It doesn't seem to be used anway.


Given  that, the system after 24 hours of typical use is nowhere near 
using up most of the memory.


I expect that the web browsers keep an eye on available memory and do 
most of their memory management/caching  in a 'fixed' allocation as well 
as the memory marked buff/cache


Here is the status just now

root@client:~# free -m
   totalusedfree  shared  buff/cache   available
Mem:   320239654   14053 3369261   22369
Swap:976   8 968

Re: goose DHCP clients to new address Was: DHCP Problem

[Jeffrey Walton]

On Sun, Dec 3, 2023 at 4:51 PM Charles Curley
 wrote:
>
> On Sun, 3 Dec 2023 22:14:51 +0100
> Geert Stappers  wrote:
>
> > I assume that the previous router is disconnected from the LAN.
>
> No. Until I solve this problem (and a few others), I will have clients
> using the old router.
>
> > The DHCProtocol has "release" for such goosing.
> > At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0]
> > The DHCPclient should forget ( "release" ) previous settings.
> > At DHCPclient do "start DHCP", client should get fresh config,
> > including the setting for the fresh router.
>
> I'm not sure how to do this. I did run on a client
>
> dhclient -r
> dhclient
>
> I observed no changes.
>
> The -r causes dhclient to release its lease. Invoking dhclient again
> should then obtain a new lease.

I don't know about Linux clients, but in the past, Windows clients
used to try to connect to the previous DHCP server for its lease info.
If the old DHCP server is still available (on the old router?), then
the client may be getting the lease info from the old server. To avoid
the problem, we disconnected the old server from the network.

You should probably just perform a hard cut-over. Shutdown the old
router, stand up the new router. After the hard cutover, force clients
to renew their leases (or wait until they do it on their own). And if
things go sideways, undo the change.

> > If that is already done, provide information to enable further help.
> > Such as name of the DHCP client program  and DHCP lease time.
>
> I am using whatever is standard on Debian Bullseye and Bookworm.
>
> root@hawk:/etc# pre dhc
> isc-dhcp-client 4.4.1-2.3+deb11u2   amd64
> isc-dhcp-common 4.4.1-2.3+deb11u2   amd64
> root@hawk:/etc#
>
> root@tiassa:~# pre dhc
> isc-dhcp-client 4.4.3-P1-2  amd64
> isc-dhcp-common 4.4.3-P1-2  amd64
> root@tiassa:~#
>
> The client's name is dhclient.
>
> default-lease-time 86400; # 24 hours
> max-lease-time 172800;# 48 hours
>
> I think for the purposes of experimentation I will shorten those to
> half an hour and one hours respectively.

Jeff

Re: Isolated Web Co Session crash Firefox-ESR

[Michael Kjörling]

On 3 Dec 2023 14:33 +0800, from jeremy.ard...@gmail.com (jeremy ardley):
>> You have swap and it is enabled?
> 
> No Swap. I prefer not on SSD

Why not?

You are definitely putting the VM allocator in a much more difficult
spot than necessary by not providing any swap space.

If I read what you provided in a different message in this thread
correctly, over half of your RAM at that particular time was being
used for anonymous pages; that is, data which has no backing on other
storage, and therefore cannot be evicted from virtual memory. Combine
this with the fact that you have no swap, and all that data _must_ be
kept in RAM because that's all there is. Combine _that_ with running
several rather memory-hungry processes (several web browsers plus
LibreOffice) _and_ the Linux default of allowing memory
overcommitting, and I'm not all that surprised that you're apparently
hitting the OOM killer from time to time.

The reason for the system slowing down seems to me to likely be that
once the system comes under memory pressure (quite possibly due to an
increase in anonymous pages), it must evict something, and only
non-anonymous (that is, backed) pages can be evicted safely. So most
likely the allocator starts evicting program code, because that can be
read back from storage later, or other forms of cache, in order to
keep room for the anonymous pages which it cannot evict. The next time
that code is needed, it must go all the way to the (horribly slow by
comparison) storage, instead of originally just writing out to swap
some anonymous pages which haven't been used in comparatively forever,
like a tmpfs that someone mentioned, or data for inactive web browser
tabs or documents you aren't doing anything active with.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: goose DHCP clients to new address Was: DHCP Problem

[Charles Curley]

On Sun, 3 Dec 2023 22:14:51 +0100
Geert Stappers  wrote:

> I assume that the previous router is disconnected from the LAN.

No. Until I solve this problem (and a few others), I will have clients
using the old router.

> The DHCProtocol has "release" for such goosing.
> At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0]
> The DHCPclient should forget ( "release" ) previous settings.
> At DHCPclient do "start DHCP", client should get fresh config,
> including the setting for the fresh router.

I'm not sure how to do this. I did run on a client

dhclient -r
dhclient

I observed no changes.

The -r causes dhclient to release its lease. Invoking dhclient again
should then obtain a new lease.

> 
> 
> If that is already done, provide information to enable further help.
> Such as name of the DHCP client program  and DHCP lease time.

I am using whatever is standard on Debian Bullseye and Bookworm.

root@hawk:/etc# pre dhc
isc-dhcp-client 4.4.1-2.3+deb11u2   amd64
isc-dhcp-common 4.4.1-2.3+deb11u2   amd64
root@hawk:/etc# 

root@tiassa:~# pre dhc
isc-dhcp-client 4.4.3-P1-2  amd64
isc-dhcp-common 4.4.3-P1-2  amd64
root@tiassa:~# 

The client's name is dhclient.


default-lease-time 86400; # 24 hours
max-lease-time 172800;# 48 hours

I think for the purposes of experimentation I will shorten those to
half an hour and one hours respectively.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: DHCP Problem, but where

[Charles Curley]

On Sun, 3 Dec 2023 22:18:22 +0100
Geert Stappers  wrote:

> Has the DHCP server been restarted?

Yes.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: DHCP Problem, but where

[jeremy ardley]

On 4/12/23 05:18, Geert Stappers wrote:

That triggered me to ask "Has the DHCP server been restarted?"



The default behaviour of most dhcp clients when they can't connect to a 
dhcp server is to maintain the settings from any previous lease.


A second default behaviour is for clients to not request new dhcp until 
their existing dhcp lease has expired.


To make sure a new dhcp setting is taken by all clients you need to

-  reconfigure your dhcp server

- restart your dhcp server

- check your dhcp server logs for any problems

- restart your dhcp clients

- check your client dhcp logs to see if the new lease info has been taken.

There can be problems where a client with a specific MAC address 
requests a specific ip address based on a previous lease but the server 
is unwilling or unable to allocate that address to that MAC. This can be 
checked in the server and client logs. It may also require flushing the 
server lease tables and client configs so they can both start out 
completely fresh.

tunnel wayland

[Geert Stappers]

In-Reply-To: <20231203201934.4b51c...@acer-suse.fritz.box>
Subject: Re: Telnet

On Sun, Dec 03, 2023 at 08:19:34PM +, debian-u...@howorth.org.uk wrote:
> Charles Curley wrote:
> > 
> >  ... even on an isolated network one should prefer ssh. First,
> >  to be in the right habit. Second because it will do things that
> >  telnet won't, like tunnel X.
> 
> Ah but will it tunnel wayland?? Enquiring minds want to know :)
> 

That question has now the fresh thread it deserves.



Groeten
Geert Stappers
Prefers subject matching message body
-- 
Silence is hard to parse

Re: DHCP Problem

[Charles Curley]

On Sun, 3 Dec 2023 20:56:20 +0100
Marco Moock  wrote:

> Did you check with a sniffer that the answer from the DHCP includes
> the new router address?

Not with a sniffer, but I did check the lease file. Neither the router
address nor the various lease times changed.



-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: DHCP Problem, but where

[Geert Stappers]

On Sun, Dec 03, 2023 at 04:03:39PM -0500, Henning Follmann wrote:
> > On Dec 3, 2023, at 14:31, Charles Curley wrote:
> > 
> > I am installing a new router which seems to work well so far.
> > 
> > I have changed the DHCP server to use the new router's address, and shut
> > the server down and restarted it. Existing clients insist on using the
> > old router anyway. Is there any way to goose clients into using the new
> > one short of manually using the ip route command?
> > 
> > 
> 
> Did you flush the old leases from /var/lib/dhcpd ?
> Just changing the config is not enough.

That triggered me to ask "Has the DHCP server been restarted?"
 

Groeten
Geert Stappers
-- 
Silence is hard to parse

goose DHCP clients to new address Was: DHCP Problem

[Geert Stappers]

On Sun, Dec 03, 2023 at 12:30:53PM -0700, Charles Curley wrote:
> I am installing a new router which seems to work well so far.
 
I assume that the previous router is disconnected from the LAN.


> I have changed the DHCP server to use the new router's address, and shut
> the server down and restarted it. Existing clients insist on using the
> old router anyway. Is there any way to goose clients into using the new
> one short of manually using the ip route command?

The DHCProtocol has "release" for such goosing.
At DHCPclient do "stop DHCP", over the wire goes DHCPRELEASE [0]
The DHCPclient should forget ( "release" ) previous settings.
At DHCPclient do "start DHCP", client should get fresh config,
including the setting for the fresh router.


If that is already done, provide information to enable further help.
Such as name of the DHCP client program  and DHCP lease time.

Oh, DHCP lease time:  What lease time is the DHCP server providing?


Groeten
Geert Stappers

[0] 
https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_message_types
-- 
Silence is hard to parse

Re: DHCP Problem

[Henning Follmann]

> On Dec 3, 2023, at 14:31, Charles Curley  
> wrote:
> 
> I am installing a new router which seems to work well so far.
> 
> I have changed the DHCP server to use the new router's address, and shut
> the server down and restarted it. Existing clients insist on using the
> old router anyway. Is there any way to goose clients into using the new
> one short of manually using the ip route command?
> 
> 

Did you flush the old leases from /var/lib/dhcpd
?
Just changing the config is not enough.

-H

Re: Telnet

[debian-user]

Charles Curley  wrote:
> On Sun, 3 Dec 2023 14:01:38 -0500
> Greg Wooledge  wrote:
> 
> > The question is whether anyone should be running a telnetd *server*.
> > On an isolated network, it might be acceptable.  But it's really a
> > bad habit that should be stomped out aggressively, as machines
> > which are currently on an isolated network might not remain there
> > forever.  
> 
> I concur, and would add that even on an isolated network one should
> prefer ssh. First, to be in the right habit. Second because it will do
> things that telnet won't, like tunnel X.

Ah but will it tunnel wayland?? Enquiring minds want to know :)

Re: Print flakes off mailing labels, use a fixative?

[Gareth Evans]

> On 3 Dec 2023, at 12:06, Gareth Evans  wrote:
> 
> ... I've never had a problem with laser-designated labels.  

I do have experience of toner falling off non-laser labels, so perhaps your 
laser labels are a duff batch, or perhaps they were mis-labelled :p

G

Re: DHCP Problem

[Marco Moock]

Am 03.12.2023 um 12:30:53 Uhr schrieb Charles Curley:

> I have changed the DHCP server to use the new router's address, and
> shut the server down and restarted it. Existing clients insist on
> using the old router anyway. Is there any way to goose clients into
> using the new one short of manually using the ip route command?

Did you check with a sniffer that the answer from the DHCP includes the
new router address?
As long as the lease time of the old lease the route may stay in the
routing table.

DHCP Problem

[Charles Curley]

I am installing a new router which seems to work well so far.

I have changed the DHCP server to use the new router's address, and shut
the server down and restarted it. Existing clients insist on using the
old router anyway. Is there any way to goose clients into using the new
one short of manually using the ip route command?


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Telnet

[Charles Curley]

On Sun, 3 Dec 2023 14:01:38 -0500
Greg Wooledge  wrote:

> The question is whether anyone should be running a telnetd *server*.
> On an isolated network, it might be acceptable.  But it's really a bad
> habit that should be stomped out aggressively, as machines which are
> currently on an isolated network might not remain there forever.

I concur, and would add that even on an isolated network one should
prefer ssh. First, to be in the right habit. Second because it will do
things that telnet won't, like tunnel X.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Telnet

[Greg Wooledge]

On Sun, Dec 03, 2023 at 11:52:51AM -0700, Charles Curley wrote:
> On Sun, 3 Dec 2023 17:00:44 +0100
> Marco Moock  wrote:
> 
> > > 
> > > How do you find 1994? It seems to be a mail from yesterday:  
> > 
> > For me it sounded like a joke.
> > 
> > Telnet is unencrypted (although it is possible to run it over TLS to
> > encrypt it) and SSH exists more than 20 years.
> 
> True. None the less, there is at least one perfectly good use for
> telnet: testing connections to servers.
> 
> charles@hawk:~$ telnet hawk
> Trying 127.0.1.1...
> telnet: Unable to connect to remote host: Connection refused
> charles@hawk:~$ telnet hawk 80
> Trying 127.0.1.1...
> Connected to hawk.localdomain.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
> charles@hawk:~$ 

Yes, there is plenty of use for the telnet *client*.  Nobody disputes this.

The question is whether anyone should be running a telnetd *server*.
On an isolated network, it might be acceptable.  But it's really a bad
habit that should be stomped out aggressively, as machines which are
currently on an isolated network might not remain there forever.

Re: Telnet

[Charles Curley]

On Sun, 3 Dec 2023 17:00:44 +0100
Marco Moock  wrote:

> > 
> > How do you find 1994? It seems to be a mail from yesterday:  
> 
> For me it sounded like a joke.
> 
> Telnet is unencrypted (although it is possible to run it over TLS to
> encrypt it) and SSH exists more than 20 years.

True. None the less, there is at least one perfectly good use for
telnet: testing connections to servers.

charles@hawk:~$ telnet hawk
Trying 127.0.1.1...
telnet: Unable to connect to remote host: Connection refused
charles@hawk:~$ telnet hawk 80
Trying 127.0.1.1...
Connected to hawk.localdomain.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
charles@hawk:~$ 

The first attempt shows that hawk does not have a telnet server on the
default port. The second shows that it does have a server of some sort
on port 80, which is assigned to http.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Print flakes off mailing labels, use a fixative?

[David Christensen]

On 12/3/23 04:05, Gareth Evans wrote:




On 3 Dec 2023, at 11:39, Tom Browder  wrote:
On Sat, Dec 2, 2023 at 5:17 PM Gareth Evans  wrote:

Are your labels "laser" labels?


Yes, DUAL INKJET and LASER


OK.  I don't have much experience of label printing, but I've never had a 
problem with laser-designated labels.

I would probably try a different brand.  I wouldn't imagine it's a hardware 
issue if the toner fuses properly to paper.

What's the printer model and type of toner in use?

Thanks
Gareth



+1


Please confirm printer, toner cartridge, and labels are all HP.  If so, 
I would contact HP.



David

Re: Telnet

[Marco Moock]

Am 03.12.2023 um 12:06:40 Uhr schrieb Michel Verdier:

> On 2023-12-02, Andy Smith wrote:
> 
> > Can someone examine the list's configuration? This email from 1994
> > seems to have only just been delivered.  
> 
> How do you find 1994? It seems to be a mail from yesterday:

For me it sounded like a joke.

Telnet is unencrypted (although it is possible to run it over TLS to
encrypt it) and SSH exists more than 20 years.

Re: Isolated Web Co Session crash Firefox-ESR

[Reco]

Hi.

On Sun, Dec 03, 2023 at 12:58:47PM +0800, jeremy ardley wrote:
> I noticed my Firefox -esr browser becoming progressively more sluggish. Then 
> suddenly I was back to the system login screen
> 
> This is not the first time this has happened although previously when it 
> started getting sluggish I killed all Firefox related process
> 
> System logs show the start of the event.
> 
> 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] Isolated Web 
> Co invoked oom-killer: 
> gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, 
> oom_score_adj=100

Tail of that particular trace always shows top memory consumers at the
very moment oom-killer was invoked.
Skipping that information can and will lead to guessing.


And in this particular case:

> inactive_anon:29781756kB
> anon_thp: 17088512kB

Do you have any relatively large filesystem, such as /tmp, mounted as
tmpfs? Any tmpfs contents are not accounted by free(1) or top(1), but
using large tmpfs with small swap can lead to funny results to say the
least.

Reco

Re: Print flakes off mailing labels, use a fixative?

[Gareth Evans]

> On 3 Dec 2023, at 11:39, Tom Browder  wrote:
> On Sat, Dec 2, 2023 at 5:17 PM Gareth Evans  wrote:
>> Are your labels "laser" labels?
> 
> Yes, DUAL INKJET and LASER

OK.  I don't have much experience of label printing, but I've never had a 
problem with laser-designated labels.  

I would probably try a different brand.  I wouldn't imagine it's a hardware 
issue if the toner fuses properly to paper.

What's the printer model and type of toner in use?

Thanks
Gareth

Filsystem för värddator?

[Martin Schöön]

Hallå,

Någon som är duktig på filsystem här?

Efter 13 år är det dags för ny dator -- stationär dator
i 'hemmakontoret'. Den gamla jobbar på bra så jag unnar
mig lyxen att inte hasta med den nya.

En av datorns arbetsuppgifter är att vara värd för några
virtuella maskiner -- både Virtualbox och Qemu. På den
gamla dator lever de virtuella diskarna på en separat
ext4-partition. Detta är lite av ett mysterium. Varför
gjorde jag så? Vad är bästa valet idag?

Övriga partitioner (/ och /home) är btrfs-partitioner
och det har fungerat hur bra som helst.

Den gamla datorn var tänkt som ren kontorsdator och hade
modesta prestanda redan när den var ny. Från början med
en HDD men ganska snart ombyggd med två HDD och RAID.

Den nya datorn förväntas få bita i lite mer ambitiösa
arbetsuppgifter så jag har spännt bågen hårdare
denna gång. Mycket mer RAM och, narturligtvis, SSD.

Finns det någon här som kan gissa varför jag inte
lät mina virtuella diskar ligga i en folder under 
/home (btrfs)? Finns det någon anledning till att
inte göra så på den nya datorn?

Det enda jag kan komma på är att dessa 'diskar' är
rätt stora filer (45 GB, 20 GB...) och att det kanske
kan vara jobbigt i kombination med ett COW filsystem.

Med tack på förhand,

/Martin

Re: Isolated Web Co Session crash Firefox-ESR

[Jeffrey Walton]

On Sun, Dec 3, 2023 at 6:21 AM jeremy ardley  wrote:
>
> On 3/12/23 13:59, Phil Wyett wrote:
> > Your system RAM total is?
>
> 32G

You might also want to try compressed memory, like zram.

> > You have swap and it is enabled?
>
> No Swap. I prefer not on SSD

In this configuration, you may want to set `vm.overcommit_memory = 2`
since there is no page file. I don't think it will make the OOM go
away, but it will set a policy more in line with what you are doing.
(It may move the OOM from some random program to the browser, since
the browser is grabbing large amounts of memory).

But I would use a swap file, and set `vm.swappiness = 1`. That tells
the OS to do just about everything except use the swap file. I use
this for all my dev boards with SDcards. The swap file is needed
because the dev boards often lack resources, like having 512 MB of
RAM. (In my case, I need to run a C++ compiler, so I have to have a
swap file or accept the Denial of Service and not get my work done).

Jeff

Re: Print flakes off mailing labels, use a fixative?

[Tom Browder]

On Sun, Dec 3, 2023 at 2:01 AM David Christensen
 wrote:
> I would not put anything through a laser printer unless it is
> specifically rated for laser printers.  Applying fixative to printer
> labels before printing sounds like a good way to damage your equipment.
> If anything, apply the fixative after printing.

Of course.

Re: Print flakes off mailing labels, use a fixative?

[Tom Browder]

On Sat, Dec 2, 2023 at 5:17 PM Gareth Evans  wrote:
> Are your labels "laser" labels?

Yes, DUAL INKJET and LASER

-Tom

Re: Telnet

[Michel Verdier]

On 2023-12-02, Andy Smith wrote:

> Can someone examine the list's configuration? This email from 1994
> seems to have only just been delivered.

How do you find 1994? It seems to be a mail from yesterday:

Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com 
[IPv6:2a00:1450:4864:20::12d])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest 
SHA256
 client-signature RSA-PSS (2048 bits) client-digest SHA256)
(Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (not verified))
by bendel.debian.org (Postfix) with ESMTPS id 55BA920B9F
for ; Sat,  2 Dec 2023 15:50:17 + 
(UTC)

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 16:00 +0800, jeremy ardley wrote:
> 
> On 3/12/23 15:37, Phil Wyett wrote:
> > Not to regurgitating info here, I will add a link below that will 
> > instruct how to adjust or disable oom-killer in a sensible manner if 
> > you wish to experiment (your choice and being cautious :-)) if it is 
> > in fact the oom-killer algorithm that is the main cause of your issue.
> 
> 
> The issue is not so much Isolated Web Co being terminated, but my entire 
> Mate session being terminated.
> 
> I wouldn't have too much problem if OOM-killer hit Firefox. I have done 
> it myself when things got slow.
> 
> However, I can't see any valid reason for the Mate session to be 
> assassinated? Or at least be inevitable collateral damage.
> 

Hi,

Not being deeply familiar with the oom-killer heuristics, I could not offer 
reasoning why 'mate' is
killed. These heuristics by default kill the most memory hogging processes in 
theory and the
consequences of this on other processes I cannot comment on.

There is one setting you may wish look at and consider.

Reading:

https://docs.kernel.org/admin-guide/sysctl/vm.html

I see the following:

https://docs.kernel.org/admin-guide/sysctl/vm.html?highlight=laptop#oom-kill-allocating-task

Setting this to '1' may trigger a strategy that does not put 'mate' in the 
firing line as it changes
the target for killing to the process call that triggers the out of memory 
condition. I am sure if
my reading of this setting is wrong, someone will correct.

This would be done of course at your own risk after doing the research yourself.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org



signature.asc
Description: This is a digitally signed message part

Re: Mailing List

[Thomas Schmitt]

Hi,

David Wright wrote:
> I'm subscribed, but I don't receive that badge of honour.
> This is from my other post in this thread—no LDOSUBSCRIBER:
>
> >   X-Spam-Status: No, score=-4.9 required=4.0 tests=CAPINIT,FOURLA,
> > HEADER_FROM_DIFFERENT_DOMAINS,LDO_WHITELIST,RCVD_IN_DNSWL_LOW,
> > T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
> > version=3.4.2

This is known to happen if the mail is sent from an address that is different
from the subscribed mail address. Maybe you discovered a new cause.


> I'm guessing your last example is Curt's.
> >   X-Spam-Status: No,
> > score=-10.5 required=4.0 tests=FREEMAIL_FORGED_FROMDOMAIN,
> > FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,LDOSUBSCRIBER,
> > LDO_WHITELIST,T_SCC_BODY_TEXT_LINE autolearn=unavailable
> > autolearn_force=no version=3.4.2

Yes. It's from:

  Subject: Re: rhs time out error?
  Date: Sun, 26 Nov 2023 16:30:02 - (UTC)
  Message-ID: 

> The only occurrence of
> the From: address in the entire email is in the From: line.
> That's no different from my own post, except for the lines at the
> very top, which show my post being delivered to me.
>
> I had thought the server was using the envelope-from in order to
> identify subscribers, yet Curt's posts, like mine, have different
> envelope-from and From: addresses, which is presumably the reason
> behind HEADER_FROM_DIFFERENT_DOMAINS.

HEADER_FROM_DIFFERENT_DOMAINS would have been my first suspicion, too.
But i see no "envelope-from" Curt's mail and yours.
Only
  Envelope-To: 
(If "envelope-from" is a typo and "Envelope-To:" differs from "From:",
then we'd probably have the situation of different sender and receiver.)


It would be interesting to see all "Received:" headers of your own
mail when it arrives back to you. I see in your mail to which i now reply:

  Received: from bendel.debian.org ([82.195.75.100]) by mx-ha.gmx.net
(mxgmx109
 [212.227.17.5]) with ESMTPS (Nemesis) id 1MZzsi-1qmfcQ0kRo-00R0wN for
 ; Sun, 03 Dec 2023 05:24:06 +0100
  Received: from localhost (localhost [127.0.0.1])
by bendel.debian.org (Postfix) with QMQP
id 0F8C9209D5; Sun,  3 Dec 2023 04:23:55 + (UTC)
  Received: from localhost (localhost [127.0.0.1])
by bendel.debian.org (Postfix) with ESMTP id 0413D20837
for ; Sun,
3 Dec 2023 04:23:42 + (UTC)
  Received: from bendel.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id 1Ym_tsLfWzf6 for ;
Sun,  3 Dec 2023 04:23:33 + (UTC)
  Received: from omta012.uswest2.a.cloudfilter.net
(omta012.uswest2.a.cloudfilter.net [35.164.127.235])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "Client", Issuer "CA" (not verified))
by bendel.debian.org (Postfix) with ESMTPS id 1A7BD209C6
for ; Sun,
3 Dec 2023 04:23:32 + (UTC)
  Received: from cxr.smtp.a.cloudfilter.net ([10.0.16.145])
by cmsmtp with ESMTP
id 9deErTpHpaga99e0vrCJA8; Sun, 03 Dec 2023 04:23:29 +
  Received: from axis.corp ([68.102.133.185])
by cmsmtp with ESMTPSA
id 9e0srwhHYTywR9e0urtWnm; Sun, 03 Dec 2023 04:23:29 +

All these headers except the first were added on the sender side, i.e
on the list server bendel.debian.org and in your mail provider's realm.

In a mail of mine to this list i see:

  Received: from bendel.debian.org ([82.195.75.100]) by mx-ha.gmx.net
(mxgmx009
[212.227.15.9]) with ESMTPS (Nemesis) id 1MMYsv-1qsRpG2aBT-00SPIm for
; Fri, 01 Dec 2023 21:11:45 +0100
  Received: from localhost (localhost [127.0.0.1])
by bendel.debian.org (Postfix) with QMQP
id 869AC20BB3; Fri,  1 Dec 2023 20:11:33 + (UTC)
  Received: from localhost (localhost [127.0.0.1])
by bendel.debian.org (Postfix) with ESMTP id 920DB20B9A
for ; Fri,
1 Dec 2023 20:11:22 + (UTC)
  Received: from bendel.debian.org ([127.0.0.1])
by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525)
with ESMTP id g1fSuxvi8ZX9 for ;
Fri,  1 Dec 2023 20:11:19 + (UTC)
  Received: from mout.gmx.net (mout.gmx.net [212.227.15.15])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits)
server-digest SHA256)
(Client did not present a certificate)
by bendel.debian.org (Postfix) with ESMTPS id 14F4520A27
for ; Fri,
1 Dec 2023 20:11:19 + (UTC)
  Received: from scdbackup.webframe.org ([91.8.169.164]) by mail.gmx.net
(mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id
1Mqs0R-1reJbZ24e1-00mwgO for ; Fri,
01 Dec 2023 21:11:16 +0100

So there is one mail relay hop more on your side, before the mail reaches
the Debian list server. I wonder whether this earns you the spam test
attribute HEADER_FROM_DIFFERENT_DOMAINS which i don't get in my mails:

  X-Spam-Status: No, score=-12.0 required=4.0 tests=DKIM_SIGNED,DKIM_VALID,

Re: Problema reportando bug

[Camaleón]

El 2023-12-02 a las 19:17 +, Aimar Urteaga escribió:

>> Me acabo de comprar un portátil nuevo y he decidido instalarle la versión 
>> testing de debian. El portátil en cuestión es un framework con el procesador 
>> AMD Ryzen™ 7 7840U. El problema en cuestión es a la hora de conectar un 
>> monitor externo si utilizo el adaptador de USBc a HDMI. Si utilizo el 
>> adaptador incluido por defecto con el portátil todo funciona perfecto, pero 
>> si en cambio utilizo un adaptador que además de HDMI adapte a USB y pongo a 
>> través de la interfaz gráfica de GNOME la pantalla principal a la exterior 
>> esta empieza a parpadear en blanco hasta que finalmente se apaga. Tras esto 
>> GNOME sigue detectando el monitor como conectado, pero este permanece 
>> apagado. Aunque posteriormente se desconecte el dispositivo y se vuelva a 
>> conectar, la pantalla no se vuelve a encender. He probado con dos 
>> adaptadores y ambos han mostrado el mismo comportamiento:
>> El UGREEN Revodok Pro 10 En 1: 
>> https://www.amazon.es/dp/B0BXDQS4BD?psc=1=ppx_yo2ov_dt_b_product_details
>> El Lemorele Hub USB C con Ethernet - 5 en 1: 
>> https://www.amazon.es/gp/product/B09ZQNCQHC/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8=1

En principio se supone que ambos funcionan con Linux sin driver, o eso 
dice la página de Amazon pero en los comentarios iniciales no veo 
ninguno sobre cómo/si funciona en Linux.

Quizá sea un problema de incompatibilidad de la salida USB-C a HDMI con 
el portátil ¿qué marca y modelo de ordenador es, exactamente?

Pruebas que haría:

- Si estás con Wayland, probar con Xorg (o viceversa)
- Probar si funciona la salida VGA
- Como te han comentado, revisa los registros con el journal, 
seguramente tengas algún mensaje de error que te pueda dar alguna 
pista.
- Baja alguna LiveCD de Ubuntu u otra distribución modernita para ver 
si te sigue haciendo lo mismo.

>> He intentado hacer un bug report pero no he sabido a que paquete le 
>> corresponde el bug no se si es problema de GNOME o de Wayland o del driver 
>> de AMD o de algún otro. No creo que sea un problema de hardware porque es 
>> común entre varios dispositivos y además requiere que sea la pantalla 
>> principal (que en principio le es indiferente al hardware).

Yo lo pondría contra el sistema gráfico (Xorg o Wayland), y según el 
controlador gráfico que uses, si se trata del libre también podría ser 
contra el kernel (por el KMS).

>> A las espera de vuestra respuesta,
>> Aimar.

> Rectifico si utilizo el adaptador incluido por defecto con el portátil da los 
> mismos problemas que el original.

Hum... eso es significativo. Descartado el hardware, pues. Pero las 
pruebas las puedes hacer igualmente  con el adapatdor que trae el equipo 
e informar del fallo si sigue sin funcionar.

Saludos,

-- 
Camaleón 

Re: Isolated Web Co Session crash Firefox-ESR

[Phil Wyett]

On Sun, 2023-12-03 at 14:59 +0800, jeremy ardley wrote:
> 
> On 3/12/23 14:46, Phil Wyett wrote:
> > The first thing I would do before any other is to enable swap and see 
> > what benefits that brings. I have no production laptop or desktop 
> > (laptop with 32G being daily driver with NVME (root) and an SSD (home) 
> > drive inside) that does not have swap. I have 8G of swap on my laptop 
> > and it does get used by the system, but only in low amounts. Others 
> > may have other strategies here, but this is where I would start.
> 
> 
> I don't think it is actually a lack of memory. What I do see is all the 
> web browsers are up there on CPU along with nvidia-modeset.
> 
> Putting in swap may delay the time things start going awry but the cause 
> won't be lack of memory
> 
> top CPU
> 
> top - 14:55:15 up 44 days, 41 min,  1 user,  load average: 0.19, 0.19, 0.19
> Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.6 us,  0.2 sy,  0.0 ni, 99.1 id,  0.1 wa,  0.0 hi, 0.0 si,  
> 0.0 st
> MiB Mem :  32023.4 total,  19201.2 free,   7118.7 used,   6564.6 buff/cache
> MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24904.6 avail Mem
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> 3433245 jeremy    20   0 2584752 210788 100352 S   4.3   0.6 0:25.77 
> Isolated Web Co
> 3423627 jeremy    20   0 1140.1g 326428 130228 S   2.6   1.0 6:12.36 chrome
> 3423253 jeremy    20   0   32.9g 387804 299712 S   1.0   1.2 2:25.86 chrome
>  723 root  20   0   0  0  0 S   0.7   0.0 269:07.26 
> nvidia-modeset/kthread_q
> 3432484 jeremy    20   0 3689468 688004 243920 S   0.7   2.1 1:01.72 
> firefox-esr
> 3433214 root  20   0   11880   5348   3196 R   0.7   0.0 0:03.16 top
> 3422887 jeremy    20   0  697716  55924  40800 S   0.3   0.2 0:07.98 
> mate-terminal
> 3423206 jeremy    20   0   32.8g 434756 252740 S   0.3   1.3 1:32.29 chrome
> 3423254 jeremy    20   0   32.4g 129252 101388 S   0.3   0.4 0:28.83 chrome
> 3428534 jeremy    20   0   32.6g 480104 145044 S   0.3   1.5 2:43.60 
> chromium
> 3428658 jeremy    20   0 1134.0g 212384 117084 S   0.3   0.6 7:09.41 
> chromium
>    1 root  20   0  168800  10412   6324 S   0.0   0.0 0:45.56 
> systemd
>    2 root  20   0   0  0  0 S   0.0   0.0 0:01.82 
> kthreadd
>    3 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> rcu_gp
>    4 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> rcu_par_gp
>    5 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> slub_flushwq
>    6 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 netns
>    8 root   0 -20   0  0  0 I   0.0   0.0 0:00.00 
> kworker/0:0H-events_highpri
> 
> 
> top memory
> 
> top - 14:58:34 up 44 days, 45 min,  1 user,  load average: 0.27, 0.23, 0.20
> Tasks: 384 total,   3 running, 381 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.8 us,  0.4 sy,  0.0 ni, 98.7 id,  0.1 wa,  0.0 hi, 0.1 si,  
> 0.0 st
> MiB Mem :  32023.4 total,  19055.2 free,   7260.6 used,   6570.2 buff/cache
> MiB Swap:    977.0 total,    968.1 free,  8.9 used.  24762.8 avail Mem
> 
>  PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
> 3422963 jeremy    20   0 4032104 979264 208004 S   0.0   3.0 5:20.33 
> thunderbird
> 3432484 jeremy    20   0 3679780 711916 250108 S   1.3   2.2 1:13.98 
> firefox-esr
> 3428534 jeremy    20   0   32.6g 480364 144980 R   1.7   1.5 2:46.34 
> chromium
> 3423206 jeremy    20   0   32.8g 434600 252740 S   0.0   1.3 1:32.66 chrome
> 3422183 root  20   0   25.0g 419692 139016 S   0.3   1.3 0:47.61 Xorg
> 3423253 jeremy    20   0   32.9g 387540 299712 S   1.3   1.2 2:28.33 chrome
>     1750 jeremy    20   0 1163816 380224   9776 S   0.0   1.2 3:53.92 
> goa-daemon
> 3423627 jeremy    20   0 1140.1g 326700 130228 S   3.6   1.0 6:19.81 chrome
> 3422581 jeremy    20   0 7293420 311912  78012 S   0.3   1.0 0:40.50 
> dropbox
> 3423600 jeremy    20   0 1134.1g 294804 128548 S   0.0   0.9 0:46.53 chrome
> 3428484 jeremy    20   0   32.7g 266044 192084 S   0.3   0.8 0:38.63 
> chromium
>     2320 jeremy    20   0 1752388 244220  12876 S   0.0   0.7 7:20.61 
> evolution-calen
> 3433245 jeremy    20   0 2584752 212408 100480 S   0.0   0.6 0:32.45 
> Isolated Web Co
>     1664 jeremy 9 -11  240828 203652   5716 S   0.0   0.6 7,25 
> pipewire-pulse
> 3433581 jeremy    20   0 296 201664  98504 S   0.7   0.6 0:03.09 
> Isolated Web Co
> 3428658 jeremy    20   0 1134.0g 200140 117084 R   4.3   0.6 7:18.18 
> chromium
> 3432583 jeremy    20   0   18.7g 191500 108380 S   0.3   0.6 0:10.79 
> WebExtensions
> 3433289 jeremy    20   0 2549968 181504  97876 S   0.0   0.6 0:03.47 
> Isolated Web Co
> 3422461 jeremy    20   0 1385296 158252  94932 S   0.0   0.5 0:20.50 
> nextcloud
> 3428536 jeremy    20   0   32.4g 152468 132780 S   0.3   0.5 0:19.69 
> chromium
> 3432350 jeremy    20   0 1134.0g 

Re: Isolated Web Co Session crash Firefox-ESR

[jeremy ardley]

On 3/12/23 15:37, Phil Wyett wrote:
Not to regurgitating info here, I will add a link below that will 
instruct how to adjust or disable oom-killer in a sensible manner if 
you wish to experiment (your choice and being cautious :-)) if it is 
in fact the oom-killer algorithm that is the main cause of your issue.



The issue is not so much Isolated Web Co being terminated, but my entire 
Mate session being terminated.


I wouldn't have too much problem if OOM-killer hit Firefox. I have done 
it myself when things got slow.


However, I can't see any valid reason for the Mate session to be 
assassinated? Or at least be inevitable collateral damage.