Re: [gentoo-user] SDDM tmp file goes missing?
On Fri, 5 Jan 2024 at 02:49, Spackman, Chris wrote: > Any thoughts on possible causes or fixes? I've also had this happen a few times over the last months, with error mails about SDDM tmp files from cron. Just wanted to pipe in and say that I don't have either rkhunter or keepassxc, so they must be unrelated. Running on openbox. I also have the 'unable to open new GUI apps' problem on a Plasma machine now and then. I had not connected the two, but maybe the same root cause. Regards, Arve
[gentoo-user] SDDM tmp file goes missing?
Good evening, I few times (like maybe 3 or 4) over the last 4 or 5 months or so, I've woken up to a slightly broken X11 session. Nothing GUI has permission to access, starting in a terminal gives this message: > Authorization required, but no authorization protocol specified I originally thought it was caused by an xscreensaver crash, but I've not been using it, and still woke up to this problem this morning. I've no idea the cause, and I'm sure everything was okay when I went to bed last night. The biggest hint came from rkhunter and anacron - rkhunter runs during the night, and when this issue happens, I get an email that includes something like: > run-parts: /etc/cron.daily/rkhunter exited with return code 1 > > Opening file "/tmp/keepassxc-chris.socket" failed, ignoring: No such device > or address > Opening file "/tmp/sddm-:0-NpHoUj" failed, ignoring: No such device or > address I've not checked keepassxc (running, in the system tray) after this, but everything GUI (that I have tried) that was already running continues to run okay, but nothing new can start. Not sure if SDDM is a cause or a symptom, but /tmp/ should usually have something like this: > chris:~$ ll /tmp/ | grep sddm > srwxrwxrwx 1 sddmsddm 0 Jan 4 06:56 dbus-blahblah > srwx-- 1 sddmsddm 0 Jan 4 06:56 sddm-:0-blahblah > srwxr-xr-x 1 rootroot 0 Dec 24 13:15 sddm-auth-blah-blah-blah Best guess, this seems to happen after 10 days to 3 weeks of uptime, but only recently. In the past, I've had as much as a month or so of uptime (usually logged into Fluxbox on X11) without issues. When this happens, I log out of Fluxbox, log back in, and all is well again. I've not updated in the last few days, so that doesn't seem likely as a cause for the most recent occurrence. Any thoughts on possible causes or fixes? Thanks. -- Chris Spackman (he / him) ESOL Coordinator, The Graham Family of Schools ESL Educator, Columbus State Community College Japan Exchange and Teaching Program (Wajima, Ishikawa 1995-1998) Linux user since 1998 Linux User #137532
RE: [gentoo-user] LiveGUI USB Image
>-Original Message- >From: Peter Humphrey >Sent: Thursday, January 4, 2024 5:01 AM >To: gentoo-user@lists.gentoo.org >Subject: Re: [gentoo-user] LiveGUI USB Image > >On Thursday, 4 January 2024 02:48:13 GMT Adam Carter wrote: >> > > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress >> > > >> > > Replace the obvious bits. >> > >> > I've tried a few values of block size over the years, but so far I >> > haven't noticed any difference. I haven't run any proper tests though. >> >> I think it's just that the default blocksize is (or was) very small >> (512 >> bytes?) so setting it to anything non-small helps a lot. >> >> eg one example (from >> https://superuser.com/questions/234199/good-block-size-for-disk-clonin >> g-with >> -diskdump-dd#234204) seems to show that most gains are in by around 16k. >> There's probably a lot of testing noise in these results. >> >> $ ./dd_obs_test.sh >> block size : transfer rate >>512 : 11.3 MB/s >> 1024 : 22.1 MB/s >> 2048 : 42.3 MB/s >> 4096 : 75.2 MB/s >> 8192 : 90.7 MB/s >> 16384 : 101 MB/s >> 32768 : 104 MB/s >> 65536 : 108 MB/s >> 131072 : 113 MB/s >> 262144 : 112 MB/s >> 524288 : 133 MB/s >>1048576 : 125 MB/s >>2097152 : 113 MB/s >>4194304 : 106 MB/s >>8388608 : 107 MB/s >> 16777216 : 110 MB/s >> 33554432 : 119 MB/s >> 67108864 : 134 MB/s > >Interesting. I think I'll stick to my usual 64MB block size. > >-- >Regards, >Peter. So, basically the default is 512, and if you're copying to something where the hardware block size is larger than that (4096 is common on a lot of things these days) then every block on the physical device has to be rewritten multiple times. (Eight times in the example case.) Needless to say, that's... rather slow. Also rather hard on your device. Once you get larger than the physical block size, as long as you have an even multiple of the physical block size, then any additional gains come solely from the IO scheduler being able to make slightly more intelligent choices with larger chunks. LMP
Re: [gentoo-user] LiveGUI USB Image
On Thursday, 4 January 2024 02:48:13 GMT Adam Carter wrote: > > > dd if=/path/to/iso-image of=/dev/sd? bs=4M status=progress > > > > > > Replace the obvious bits. > > > > I've tried a few values of block size over the years, but so far I haven't > > noticed any difference. I haven't run any proper tests though. > > I think it's just that the default blocksize is (or was) very small (512 > bytes?) so setting it to anything non-small helps a lot. > > eg one example (from > https://superuser.com/questions/234199/good-block-size-for-disk-cloning-with > -diskdump-dd#234204) seems to show that most gains are in by around 16k. > There's probably a lot of testing noise in these results. > > $ ./dd_obs_test.sh > block size : transfer rate >512 : 11.3 MB/s > 1024 : 22.1 MB/s > 2048 : 42.3 MB/s > 4096 : 75.2 MB/s > 8192 : 90.7 MB/s > 16384 : 101 MB/s > 32768 : 104 MB/s > 65536 : 108 MB/s > 131072 : 113 MB/s > 262144 : 112 MB/s > 524288 : 133 MB/s >1048576 : 125 MB/s >2097152 : 113 MB/s >4194304 : 106 MB/s >8388608 : 107 MB/s > 16777216 : 110 MB/s > 33554432 : 119 MB/s > 67108864 : 134 MB/s Interesting. I think I'll stick to my usual 64MB block size. -- Regards, Peter.
