Cannot launch dietpi-config

Hi folks,

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>                    │

Did you tried to reboot?

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.

Try to connect via SSH and run htop to check what is going on.

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.

filtered out - still the same:

Probably a zombie process. Reboot should fix it

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. :frowning:

Aaand the ghost process crazyness is back.

Can you close the RDP session and simply use SSH. Maybe some double click on the RDP opening multiple windows.

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.

probably @MichaIng has in idea what could create these blocking processes.

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 :thinking:.

I may have been occasionally closing the script window. Could that cause it? I don’t remember 100%. I can keep a eye on it.

Yes, this could be a good reason.

Ok, I’ll keep an eye on it. But I thought that closing terminal window is supposed to send SIGTERM to the script.

Closing the terminal (or lose connection for some other reason) sends a SIGHUP. SIGTERM can only be send by other processes, I think.

I mean terminal as in when you are in GUI running a shell script. Not remote terminal.