When I try to launch the config (while logged in headless via XRDP), it tells me that another process is using it, and when I hit retry the PID of interfering process is changing every moment no matter how fast I retry, so it’s hard to figure out who is calling it. I tried greping the PID from all the logs I could think of, but didn’t find anything.
Any advice on how can I troubleshoot it?
Thank you
│
│ WARNING: Concurrent execution of DietPi-Config detected │
│ │
│ Please check if one of the following applies: │
│ - This script already runs on another terminal/SSH session. │
│ - Currently a cron or systemd background job executes the script. │
│ - You started this script from within another DietPi program, causing a │
│ loop. │
│ │
│ Please assure that the concurrent execution has finished, before retrying, │
│ otherwise cancel this instance. │
│ │
│ The following info might help: │
│ 62355 root pts/1 | | \_ /bin/bash │
│ /boot/dietpi/dietpi-config │
│ 62724 root pts/1 | | \_ /bin/bash │
│ /boot/dietpi/dietpi-config │
│ │
│ <Retry> <Cancel> │
│
I was going to do it last resort.
I am trying to learn how to figure things out. I am genuinely curious what is spamming it with a new PID every millisecond.
this is weird, because the only PID in the 70000s is whiptail, and if I understand correctly it is the dialog that asks me to retry or cancel diet config attempt.
thank you for your help
sorry for reusing the thread for another, but I am not able to create another one for 12 hours (must be anti spam measure for new accounts):
I was curious how to ajust touchpad scroll speed (with 2 fingers)? I tried recommendations for Debian that I googled up (like editing /etc/X11/xorg.conf.d/90-touchpad-conf), but that file doesn’t even exist, and none other suggestions worked (probably because DietPi is so heavily modified).
And google for "dietpi" touchpad scroll speed gives no relevant results.
How can I ajust it? It’s scrolling so fast I cannot use it at all as the slightest scroll scroll entire long document/terminal output. It’s driving me crazy.
There should be not that much modification. We just have some automation but not that we modify Debian. Everything on Debian should work same way on DietPi.
Restart helped with the zombie process.
But now chrome stopped working - garbled up artifacts.
I tried increasing VRAM split to 256 MB, but that didn’t help.
Thank you for your help.
I would have seen multiple windows in the taskbar, no?
Just experimented: restarted and then started opening and closing diet-config (and the software module as well). After 5 openings/closing the problem manifested again. Something is being very fragile here.
If you think XRDP is the culprit, I can try nomachine. I love SSH, but sometime GUI is nice to have, and I’d like to make sure my setup is problem-free despite of whether I use SSH or XRDP,VNC,NoMachine/etc…
I found this article about ghost processes:
and tried using suggested command on the parents of the zombie kill -s SIGCHLD pid and even on the zombie PID itself, but that didn’t help. Very peculiar.
BTW, Chrome is still messed up even after restart despite my not having done a single thing to it apart from installing uBlock Origin. DietPi is also a fresh install that I did ~8 hours ago.
Installed Firefox, and it’s working fine, but like WTF is going on with Chrome, lol.
The concurrency check does not really check for a concurrent process (which is a very slow check) but whether the related working directory is already present, /tmp/DietPi-Config, respectively /tmp/DietPi-Software. Those are created when starting the script, as working directory, and removed when exiting the script.
Your htop indicates that the script instances which created the directories are indeed not running anymore. So they must have been hard killed (no simple SIGINT or SIGTERM or regular exit, but SIGKILL) to not leave a chance to remove the directories via EXIT trap.
Do you exit all scripts before closing the RDP session? Probably XRDP kills the current session and all child processes hard via SIGKILL when just closing the RDP client .
.