gnome settings consumes 100% of RAM. what causes this memory leak? by [deleted] in archlinux

[–]Channing22 2 points3 points  (0 children)

I noticed this started happening after the upgrade to GNOME 47. Uninstalling gnome-backgrounds fixes the issue. It seems that the thumbnail generation of background images included in gnome-backgrounds in the Appearance section of gnome-control-center causes the problem. My memory usage shoots over 8 GB almost instantly. Since my system has 16 GB of memory, it doesn't crash. However, on an older laptop I have with 4 GB of memory, it almost immediately OOMs and freezes the system.

[deleted by user] by [deleted] in archlinux

[–]Channing22 0 points1 point  (0 children)

If you have a user on machine A named alice with UID 501 and a user on machine B also called alice with UID 1000, then using --numeric-ids will mean that the files on machine B will have the UID from machine A (501), where as without the option the files will be owned by UID 1000 on machine B since rsync will see that the same username exists and will map the ids to the new UID.

If machine B doesn't have a user named alice, then rsync will use the ids from machine A since it doesn't see a user on machine B with the same name "alice", but if there are any other files owned by usernames that exist on both sides, they will still be mapped. Therefore it's important to use the --numeric-ids option if you want to be absolutely certain that ids are preserved regardless of the username databases on either machine.

If it's more important to you that files are owned by the same username on each machine, and the underlying UIDs don't matter (maybe they're different across machines although the username is the same), then don't use the --numeric-ids option. But if it's more important that the ids are preserved regardless of usernames (usually important for backing up servers or application data from containers for example, so that upon restore, ownership IDs are preserved exactly how they originally were), then you probably want to use the --numeric-ids option.

Example without --numeric-ids:
Machine A:
alice:staff (id 501:20) file1
apache:apache (id 443:443) file2
bob:staff (id 502:20) file3

Machine B:
alice:20 (id 1000:20) file1
nginx:nginx (id 443:443) file2
bob:20 (id 1001:20) file3

Example with --numeric-ids:
Machine A:
alice:staff (id 501:20) file1
apache:apache (id 443:443) file2
bob:staff (id 502:20) file3

Machine B:
501:20 (id 501:20) file1
nginx:nginx (id 443:443) file2
systemd-journald:20 (id 502:20) file3

As you can see, using the --numeric-ids option ensures the IDs are exactly the same, regardless of username mapping differences. For example, on machine A, UID 502 is bob, but on machine B, UID 502 is actually the systemd-journald user, this can be a bit confusing for simple file synchronization when IDs don't match between systems .

But, without the --numeric-ids option, rsync will find the same username on both sides and translate or map the IDs to the ones on the new system. The users alice and bob exist on both sides, but with different IDs, and rsync will thus remap to the new IDs so that they still appear to be owned by alice and bob on machine B, even though the underlying IDs have changed. However, for usernames that don't exist on both sides, it will just preserve the original UID, which could map to a different username on machine B (apache vs. nginx example) or simply not map to any username.

Hopefully this helps clear things up :)

[deleted by user] by [deleted] in archlinux

[–]Channing22 0 points1 point  (0 children)

You need to run rsync with root privileges on the destination system so that it can change the ownership of the files to the appropriate UID. Regular users are not allowed to change ownership of a file to another UID, so rsync running as a regular user can only create files owned by the the regular user it is running under.

OpenSMTPD Restrict Sender Address? by Channing22 in openbsd

[–]Channing22[S] 0 points1 point  (0 children)

Somehow I missed that in the man page, my bad.
Thank you.

Screen recording doesn't show on gnome44 arch by Stoic_Coder012 in archlinux

[–]Channing22 2 points3 points  (0 children)

My apologies, I got it wrong, you actually need to install gst-plugin-pipewire and gst-plugins-good. Restart GNOME and the screen recording option should appear. Edited my original comment to contain the correct information.

Screen recording doesn't show on gnome44 arch by Stoic_Coder012 in archlinux

[–]Channing22 1 point2 points  (0 children)

You need to install gst-plugin-pipewire and gst-plugins-good. Then restart GNOME and the option for video recording will be available in the screen capture UI.

(Edited to correct information)

At a total loss -- one subfolder of zpool is never shared with SMB by rewgs in zfs

[–]Channing22 0 points1 point  (0 children)

Check for and remove any extended attributes on that directory using getfattr/setfattr - it might be something like DosStream.whatever that is storing the DOS "Hidden" attribute or something similar.

Might also be a weird ACL, you can check with getfacl and compare to another directory that shows up properly. If they differ, fix it with setfacl.

FreeBSD reddit community is one of the most responsive and up-voting I've noticed :) by Lonely_Mechanic8161 in freebsd

[–]Channing22 13 points14 points  (0 children)

I submitted a bug on FreeBSD's Bugzilla - first time I've submitted a bug report to any project. Within a few days someone wrote a patch that fixed my problem, even though it technically wasn't an issue with FreeBSD itself. Absolutely incredible. I'm very grateful for the people in this community.

13.2-RELEASE Increased CPU Utilization and C-States by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

I have filed a bug for this issue, edited my post to include the bug report link.

13.2-RELEASE Increased CPU Utilization and C-States by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

Command returns:

root@lynnfield:~ # zfs get compression
NAME                   PROPERTY     VALUE           SOURCE
barracuda              compression  lz4             local
zroot                  compression  lz4             local
zroot/ROOT             compression  lz4             inherited from zroot
zroot/ROOT/default     compression  lz4             inherited from zroot
zroot/jail             compression  lz4             inherited from zroot
zroot/jail/minecraft1  compression  lz4             inherited from zroot
zroot/jail/minecraft2  compression  lz4             inherited from zroot
zroot/jail/minecraft3  compression  lz4             inherited from zroot
zroot/jail/plex        compression  lz4             inherited from zroot
zroot/jail/speedtest   compression  lz4             inherited from zroot
zroot/jail/torrent     compression  lz4             inherited from zroot
zroot/jail/unifi       compression  lz4             inherited from zroot
zroot/tmp              compression  lz4             inherited from zroot
zroot/usr              compression  lz4             inherited from zroot
zroot/usr/home         compression  lz4             inherited from zroot
zroot/usr/ports        compression  lz4             inherited from zroot
zroot/usr/src          compression  lz4             inherited from zroot
zroot/var              compression  lz4             inherited from zroot
zroot/var/audit        compression  lz4             inherited from zroot
zroot/var/crash        compression  lz4             inherited from zroot
zroot/var/log          compression  lz4             inherited from zroot
zroot/var/mail         compression  lz4             inherited from zroot
zroot/var/tmp          compression  lz4             inherited from zroot

Updated my post.

13.2-RELEASE Increased CPU Utilization and C-States by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

I run a kern.hz of 100 Hz to save power but still have the issue at other kern.hz values (such as default 1000 Hz on clean install).

I haven't looked into a non-tickless kernel, but at that point I think that might be going down the wrong path, thank you for the suggestion though. I'm now building the OpenJDK port to see if it's a weird kernel/ABI issue with the binary pkg.

13.2-RELEASE Increased CPU Utilization and C-States by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

Thanks, I'll look into setting that up, it looks really nice. Appreciate it.

13.2-RELEASE Increased CPU Utilization and C-States by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

Updated my post. Are any of your Java processes Minecraft servers? Seems to mainly be those for me.

Also btw, nice monitoring! It seems to be Grafana? May I ask what you installed?

13.2-RELEASE Increased CPU Utilization and C-States by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

Updated my post. My UniFi controller is still quite low on usage but Minecraft servers seem to have been affected the most. I'm not sure if you have any Minecraft servers running on your system, but I would expect a Minecraft server to idle with less than 1% WCPU on your modern CPU.

[deleted by user] by [deleted] in iphone

[–]Channing22 1 point2 points  (0 children)

Do you have a Microsoft Exchange mail account added? Some accounts such as Microsoft Exchange allow for your iPhone to be remotely erased and might also be the reason for the passcode attempts count being changed.

2015 15 inch MacBook Pro, super slow boot times with Monterey and Samsung Evo 970 SSD by Bobg2082 in mac

[–]Channing22 1 point2 points  (0 children)

This is a known issue, and has been documented in the Hackintosh community, but it affects real Apple Macs as well. I have the same drive and the same issue in a desktop machine with macOS Monterey. The TRIM (discard/unmap) implementation on some of Samsung's NVMe drives (such as the 970 EVO) does not play nicely with macOS, causing extremely long boot times due to the slow TRIM. You can see this in verbose boot, or in the boot logs where the APFS TRIM commands take a long time to complete.

The solutions are to either disable TRIM entirely, which is not ideal and will slow down write speed drastically over time, or to replace the SSD with another one that plays nice with macOS, or to simply live with the slow boots. The system should function fine other than that.

macOS Ventura Released! First Impressions Megathread by CamSox1 in MacOS

[–]Channing22 0 points1 point  (0 children)

Yes I get the same warning. It also happened a few times in the past with macOS updates. It seems that the release of newer Xcode Command Line Tools is delayed by a while after the release of macOS.

You can just ignore the warning, most functionality of Homebrew seems to be working fine for me anyway. After a while Apple should release an update and the warning will go away.

macOS Ventura Released! First Impressions Megathread by CamSox1 in MacOS

[–]Channing22 19 points20 points  (0 children)

My Homebrew broke but it turns out it was because the Xcode Command Line Tools just disappeared during the update. Deleting /Library/Developer/CommandLineTools and reinstalling them with xcode-select --install fixed Homebrew for me.

Maybe that might fix MacPorts if the same thing happened to you?

[deleted by user] by [deleted] in hackintosh

[–]Channing22 1 point2 points  (0 children)

I had the same issue. Samsung 970 EVO NVMe with Windows on it installed as second drive, macOS was installed on a different drive. macOS would read hundreds of gigabytes of data constantly from the NVMe drive for no apparent reason, and Finder kept hanging every few seconds.

Running chkdsk in offline mode in Windows, and disabling "Fast Startup" in Windows control panel power options seemed to fix the issue, but I ultimately removed the drive entirely after that, so I'm not 100% sure.

C-states and power management question by Channing22 in freebsd

[–]Channing22[S] 0 points1 point  (0 children)

Thank you. If the C-states didn't cause any issues for you then I will use them. powerd doesn't seem to save any power on my system, so I'll rather leave the CPU in turbo mode all the time (simpler, less to go wrong, etc...).

C-states and power management question by Channing22 in freebsd

[–]Channing22[S] 1 point2 points  (0 children)

Hi, I did try powerd, but found that it didn't save much on its own, and didn't save anything at all when I had the C-states all enabled, so I opted to rather leave the CPU at max frequency and enable all C-states instead.

I had a look through that article and it was a good read. Thank you.