On 2025-06-27 15:51:49 +0200 Riccardo Mottola <[email protected]> wrote:
> Hi, > > Tim Sheridan wrote: >> I’ve hit this a fair bit too, but it’s usually too late to be clear on >> the exact cause by the time I hear a fan spin up and spot what’s >> happened. I was suspecting mine being triggered by the use of keyboard >> shortcuts in GWorkspace (e.g. creating directory, moving a file to >> recycler). It seems to happen less when I’m not using GWorkspace keyboard >> shortcuts so heavily, but I’m not very certain on this! > > It happens to me without shortcuts, but it could be related to folder > creation, > > I think I was somehow able to reproduce the issue (but of course not > reliably). > > GWorkspace was running for a day, no issues. No problem. > > I created and renamed a folder and instantly got a windowmaker "refresh" > (althout it doesn't leave me a core). > > Short afterwards I noticed GWorkspace consuming CPU. > > I did not notice always windowmaker restarting with the CPU issue, but in > this case I think there certainly is a connection. > > Of course I created folders or renamed files a lot of time without issues... > so wonder! > > Riccardo > > > Hello Ricardo and Tim, Thank You for the on going investigations on GWorkspace. I have tuned my environment, and I had no issues for several days, which is not saying it could not happen. See and wait... There are the three modifications I applied: 1) To avoid well known idle state issue on RPI machines (sleeping mode producing a hardware issue) I have finally added only two xset commands in ~/GNUstep/Library/WindowMaker/autostart: xset -dpms xset s off Due to the low consumption, it is no matter to manage power on such tiny SBC. And of course, I did not set Window Maker to ignore xset commands. And, as another precaution, I never let any removable media connected to the USB port if I do not use it. And also I launch InnerSpace every time I leave my computer... Born to be alive! 2) Because I did not like those error messages ending the Xsession, I reverted to a more classic .xinitrc: - Until now, I was using a tip in .xinitrc to make GWorkspace the leader of the Xsession like this: wmaker & exec openapp GWorkspace It was appealing, because I could terminate the Xsession using the menu of GWorkspace. But, after reading again and again the academic way to set the Xsession, it seemed to me that the only way was to preprend "exec" before the window manager (i.e. wmaker) so it becomes the Xsession process leader. And as I could also read that it should not be a good practice to launch graphical apps from autostart (see the file above) I was driven to the only way to launch GWorkspace and it is after Window maker has launched itself, using then the attributes of the window application (resulting in the saved WMWindowAttributes and WMstate when the session terminates). So my .xinitrc became minimalist: exec wmaker --noclip P.S.: I am sourcing GNUstep.sh within my .profile, before the Xsession starts. So I am able to build apps where ever I am. 3) To have the removable media mounted on the Desktop and be able to unmount it with DND onto the Recycler, I need to keep the desktop of GWorkspace ever visible and it is also this layer which shows my background wallpaper. The inconvenient is that exiting the Desktop needs now two steps: a) To quit first GWorkspace; b) To open the Window Maker exit session. But this way, I know every state is well saved and I do not risk to corrupt ddbd or any thing else GWorkspace and Wmaker use to save on exit. This way, I feel now my desktop solid as a rock. To have a complete view, and to be able to compare our respective experience, this is how I built again GWorkspace. My config args were: " --with-inotify --enable-gwmetadata" So, in addition, I have a MDFinder.app installed. I found the recent searches I made within GWorkspace very quick and efficient. And so, I am guessing about this indexing activity: a) Are MDFinder and the Finder Panel related in any matter ? b) Maybe the indexing process was waiting for an idle period to start, so I wonder if it could explain why my issue was related either with removables devices (new filesystem node mounted to te system and so a need to index) and in the same time, a probable loss of power that empeached this drive exloration and indexing... Last consideration, the way devices are mounted to the filesystem: This is my /etc/fstab: proc /proc proc defaults 0 0 PARTUUID=d9c86127-01 /boot/firmware vfat defaults 0 2 PARTUUID=d9c86127-02 / ext4 defaults,noatime 0 1 # a swapfile is not a swap partition, no line here # use dphys-swapfile swap[on|off] for that UUID=5B74-A562 /mnt/CLEPAT vfat defaults,noauto,users,rw,nofail 0 0 Well, I am guessing why the "noatime" option is set only on the root partition, even with ext4, maybe to preserve the SD card? (this setting is from Debian RPI Lite OS, not mine). And I consider the line I added (begining with UUID): maybe adding noatime could narrow the indexing process in that case too? Or is it inconsistent because vfat ignore this parameter in its filesystem? Well, to summarize my more stable desktop experience: - Avoiding hardware issue specific to the Pi. - Most consistent Xsession with Wmaker as the process leader and respect of the recommended way of launching GWorkspace within this window manager. - Precautions about removable devices and idle periods. About WindowMaker apparently auto-restarting, I could notice this until now, less frequently and only in this case: - In GWorkspace menu, exit command (not logout): often does what it is expected to do (exiting GW) but sometimes, making WindowMaker (so the process Leader) to restart. It is like a bad SIGNAL, and I wonder why. Is it related to a misinterpreted DBus directive? In my case, I also built and installed libdbus, but not absolutlely sure it is used between wmaker and GWorkspace communication. This is now beyond my knowledge. P.S.1: Maybe you could provide us a procedure to make the same automated tests on different hardware. Apart my beloved fanless Pi400, I can also test on an old noisy Intel Core i5 MacBook I renovated with SSD and enhanced RAM... of course also under GNU/Linux and with any VM we can think of... P.S.:2: to test a longer uptime, I let my Pi stay on this night... Will see tomorrow... -- Patrick Cardona - Pi400 - GNU/Linux (Debian 12 aarch64: RPI OS Lite) Xorg (1:1.7.1-1.2) - libcairo2 (1.16.0-7+rpt1 arm64) Window Maker (0.96.0) - GWorkspace (1.1.0 - 02 2025) - Theme: Heritage - MUA: GNUMail (1.4.0)
