Oh, that’s a different issue than I thought y’all were talking about. I can reproduce it, but directly logging into Usermin works fine. I don’t know why it’s saving anything when just linking you to Usermin, obviously a bug. We’ll need to wait until Ilia wakes up to tackle it, as I’m about to hit the sack, too.
We remodeled several things in the systemd unit files for Webmin and Usermin (to fix a bug, and to simplify it and make it more like a regular old system unit rather than one that wraps an old init style startup where we manage the process fork ourselves). I assume there’s something that’s assuming the old behavior (but, again, I think it’s a bug that we’re even trying to write something when logging into Usermin).
It was introduced by the recent Usermin systemd service change. Virtualmin was still using an old handoff path that briefly stopped/started Usermin and then reloaded it via the PID file.
With the new systemd/no-fork service model, that exposed a timing race where the PID file might not be available yet.
Do you want a quick broken release or a working one? Quick and good are sometimes possible too, but usually they’re mutually exclusive. It’s easy to introduce much worse problems while hastily trying to solve another.
I am happy to wait till a release fixes it entirely, as Joe has pointed out a direct Usermin login at :20000 is fine. I can understand other peoples frustration I guess if they have users where this problem causes problems, if it does even. I am really quite liking UM.
It’s a bit like a underatted rock band like Budgie or Toto