Is this really still necessary? Can Webmin really no longer reliably restart itself (or be restarted on package updates)? If so, that remains our most urgent problem, I think…
[09/Dec/2022:16:48:07 -0700] [192.168.1.2] /virtual-server/index.cgi : Perl execution failed : Modification of a read-only value attempted at /usr/share/webmin/virtual-server/virtual-server-lib-funcs.pl line 923.
As for my back… Yes, I’m doing amaaazingly well. In fact, better than I could believe. Bottom line (for the many who have, or know someone with, back issues): a couple of years ago the technology for a large fraction of back surgeries changed. As long as they only need to remove stuff (“decompression”) and not put anything in like screws and spacers (“fusion”), it can now be done using digital microscope and live xray (not laparoscopic/endoscopic)… outpatient instead of staying in the hospital. I went home four hours after arriving, gently exercised the next morning, and was done with pain meds three days later! Eight weeks and I’m no longer restricted from any activities …
My advice to older friends now: don’t wait. Find out if you can get your back issue fixed now; you don’t want to wait for it to get worse! (Fusion surgery is still a big deal with long recovery and risk of complication.)
@Jamie , @Ilia - I did some code reading to attempt understanding of why there’s a read-only value involved at all (since read-only is not exactly a normal Perl concept )
Not at all sure I’ve identified the real issue, however I did note something that appears potentially dangerous. See also the link below to a list of reasons for such errors:
In list_domains() and many other subs in virtual-server-lib-funcs.pl (and a few other places in the source), a number of temp variables are defined as “local” rather than “my”. This can have huge consequences and I wonder if those who wrote the code understood the implications at the time?***
my foo defines a separate fully local-scope variable foo. It is used instead of any global of the same name. It is not visible to any routine called from the current scope (unless passed in.)
local foo dynamically redefines global variable foo, and that variable becomes visible to any routines called from within the current context. This remains true until the current context exits.
Obviously they are not interchangeable. Obviously my is what you want for truly local vars.
Not exactly the issue. The source of the problem is that you cannot modify Perl predefined variables like $_[0] or $_ and other, unless assigned to a lexical variable.
You’re right about the use of local … a lot of that code was written a long time ago, and local was the wrong choice. I’m slowly going through and switching over to my. It’s a bit complex though, as there are a few cases where local is actually required, so we can’t just do a global search and replace.
Makes sense… two of the common reasons in the list I provided. Pretty clear why this is subtle!
You don’t necessarily even know that $_ or $_[0] is being modified! A hidden element in function calls.
Someday maybe there will be debug tools that identify such things in more detail. (Might already exist; I have a friend who is an amazing Perl expert… will ask him…)
(and @Jamie) my lives-Perl friend suggested using the Carp package to reveal what’s up. Nice! It has a replacement for “die”… “confess” shows the calling stack.
use Carp;
…
confess “xyz”;
a = b or confess; # (normally “or die”)
Then I tried ... or confess; on the error line. That didn’t help. But inserting confess "here"; ahead of that line made it clear:
virtual_server::list_domain_users(undef, 0, 1) called at /usr/share/webmin/virtual-server/index.cgi line 71
Yep. index.cgi line 71: @lusers = &list_domain_users(undef, 0, 1);
So, first param $d or $_[0] is undef
So, the line causing this fatal error can’t run: my $qfile = $quota_cache_dir."/".$_[0]->{'id'}
(NOTE: the Carp package also has cluck(); which is like confess(); without terminating. A nice call stack for debug purposes. )
I hope that helps!
In my case, I have a hidden domain with associated users, and an aliased domain. The aliased domain is what is publicly visible. Works great in postfix (has worked nicely for over 20 years!)… but yes… VirtualMin thinks there are no associated users in the install
I will try to find time to work out why the users are invisible.