When started from the menu, it comes up but lock up as soon as you try to do anything, such as search for a known file (Thunderbird for example).
If run in a terminal via sudo synaptic itnimmediately errors saying that it appears that you are running as root in a wayland environment. As far as I can tell only the xorg/xserver environment is the only thing running.
Dietpi is the latest version (downloaded a week ago).
Can this be similar to KDE Plasma like described in chapter 2.2.5 in the blog?
Wait for a longer time, e.g. monitor it with htop in another xterm window.
Maybe a behaviour of synaptic not being allowed to run with root permissions. And using sudo is doing exactly this, running a command with root permission.
It works here on Cinnemon (minimal/core install) with a root user session 
. Also searching for “thunderbird” worked, showing me the resulting package.
Can you try to
apt install dbus-user-session
and at best reboot to assure the X session is started with new shared per-user dbus session.
I just added this as default to our X11 installs. Previously we used dbus-x11 which creates a dedicated per-user per X11 display dbus session.
Well, I just got some time to try to get synaptic working on my Pi 4b.
dbus-user-session is already installed.
Htop shows cpu utilization of 100% as soon as you try a search and never slows down. After waiting for 3 minutes or so I tried to exit the program but it was ignoring all key/mouse actions. I have duplicated the on 3 different desktops.
I do know synaptic works fine on a Raspian lite base with cinnamon desktop, so it must be something in dietpi.
Just did a fresh install of dietpi on my rpi 4b, before installing cinnamon I installed dbus-user-session. And after cinnamon was installed, installed synaptic and the exact same results - 100% cpu utilization and lack of mouse control when trying to shut it dowm.
Can you try to enable APT cache, and if that does not change something disable APT list compression, via dietpi-config > Advanced Options > APT?
Depending on your RAM size and utilisation and root drive durability, you may also have them in RAM.
Will be doing another fresh install of dietpi and cinnamon in a dy or so and will try your suggestions then.
Did checking using a fresh install of dietpi & cinnamon one one test drive, and the same with raspian lite and cinnamon on another drive.
Checked the status of synaptic using htop on both setups, Both intalls of synaptic showed the same files being installed.
Ran synaptic from the menu, but noticed major differences in what htop showed.
Dietpi w/ cinnamon:
htop entries for synaptic looked somewhat like this:
1234 cinnamon-launcher
|_ cinnamon --replace
|_ /bin/sh synaptic-pkexec
|_ pkexec /usr/sbin/synaptic
note: the above entries should indented for each new command, but they seem to show as all starting from space 1. Looked fine when I entered them and are correct in edit mode.
Raspian lite w/ cinnamon
htop entries for synaptic somewhat looked like this:
1234 /bin/sh usr//bin/synaptic-pkexec
3456 pkexec /usr/sbin/synaptic
One other bit of info, I checked out the htop entries for synaptic on my Linux Mint box and they were the same as the raspian lite/cinnamon data.
Not sure why the major differences, but this info can help in finding why synaptic maxes out the cpu and basically locks up when you try to use it.
The htop shows an identical setup, only the tree view is enabled on DietPi by default (press F5), which shows parent and child process relations.
Did you try to adjust the APT cache, i.e. enable cache, disable list compression, then apt update, before using Synaptic?
Default settings are cache on disk and compression enabled. First disabled compression and rebooted, did apt update. No change in Synaptic (100% disk utilization when you try a search and hard to shut it down). The tried it with both compression and cache disabled. Again, no change after a reboot and apt update. Reset apt settings to default as that does not appear to be the problem.
Beginning to think it will be a choice of not having synaptic working on dietpi (verified with 3 different of the desktops listed in dietpi-software using fresh installs of each) or going back to raspian lite for a fully functional desktop where all common programs seem to work properly. I would prefer dietpi, but am not overly interested in the hassle of getting a very common problem to work properly.
Well I can tell you thaqt on my pi 4b it nstarts up just fine, but when I try to do a search (for thunderbird as an example) it goes to 100% cpu utilization and starts ignoring any and all other input (i.e. shtdown of the program). I have waited for 5 minutes for the “search” results to show up before giving up. And on the same pi 4b using a raspain lite base with basic cinnamon desktop install, the search has never taken more than 30 seconds or so to complete and show the reults.
So after using the different dietpi desktops in the dietpi-software listings (each with a fresh install to a blank ssd) and after installing synaptic I have had exactly the same results when trying to do a search.
This probably my last post on this subject as I am more interested in having a fully functional desktop than wasting my time trying to figure out why a very common program won’t work. I guess dietpi will just be used for my server based needs.
Please try with:
apt updatesynapticRaspberry Pi OS has the cache enabled on disk, like Debian general default.
Made absolutely no difference. Started a search and cpu goes to 100% and stays there. Gave up the search and force closed the program after 3 minutes.
Ok did one more test.
locals and apt cacheAPT cache : [On disk]
APT lists : [In RAM]
List compression : [Off]
apt update
apt install cinnamon-core
dietpi-software install 6
dietpi-autostart 16
apt install synaptic
reboot
root
synaptic without issuessynaptic without issuesDue to whatever reasion I’m not able to replicate the behaviour.
Did you try while logged in as a non root user? I normally do the initial first run setup as root, but then make a new user and do the desktop install and everything else using sudo as needed as my non-root user.
JUst did a fresh install using the steps you listed (working as root). After everything was installed did a check on synaptic (as root) and for the first time everything went properly.
Added a new user and logged as that user and synaptic worked properly (again for the first time). Looks like something got fixed in the background as now it is all good to go.
At least not on our side
Two years later and on a different SBC, i-ve got Orange Pi 3B (with 4GB RAM), and i stumbled onto the same problem. Synaptic was dysfunctional. Also apt search command in CLI would take ages to complete.
Tried to change these options that you give above, namely cache on disk and compression disabled. It was slightly better, at least synaptic would not crash completely, but still way too slow. And one core of a processor was always 99-100%.
And then i changed – APT Lists: [In RAM]
Wow, what a difference! Now it works as expected.
Yeah putting things in RAM of course speeds things up massively. But this is not even Debian default. Debian ships with all enabled but on disk. Whether lists are in RAM or on disk actually should not make such a big difference when the cache exists already. Can you try to put them on disk again, disable compression, assure the cache is enabled (on disk as well), then run apt update once before starting synaptc. What makes things things so slow is when:
apt wrapper which uses xz or whichever decompressor manually to uncompress all lists before forwarsing the call. But that defeats the purpose of the compression, of course, just shows that APT is for whatever reason handles compressed lists very inefficiently.However, for SD cards, the reduces disk writes are significant, easily 150 MiB disk writes less per apt update compared to Debian defaults.