Repeated error mails from CRON (/etc/webmin/virtual-server/bw.pl)

After having upgraded to 3.71 I started to get hourly error mails stating:

Day '' out of range 1..31 at /usr/share/webmin/virtual-server/feature-mail.pl line 3129

The subject was: "Cron <root@uhura> /etc/webmin/virtual-server/bw.pl"

I use Postfix and re-checked the configuration without issues. Although I did restore multiple servers from backups yesterday (complete recreation), I only got the error mails after the upgrade.

Status: 
Active

Comments

Looks like an error parsing your mail log. The work-around is to edit /usr/share/webmin/virtual-server/feature-mail.pl , and change lines 3129 and 3130 to :

                        eval { $ltime = timelocal($5, $4, $3, $2,
                            $apache_mmap{lc($1)}, $tm[5]); };

However, I would be interested to see your mail log file /var/log/mail.log, to see the invalid line. Could you email it to me at jcameron@virtualmin.com ?

Yup, sent you the file. The work-around does indeed work, thanks!

"The work-around".

Does the above mean that there is going to be a 'fixed upgrade' for the latest upgrade?

I haven't run the upgrade from yesterday yet in case this happened again. If there is going to be another 'upgrade-fixing-upgrade' this month, when will you be releasing it? I'll wait for that one (if there is one) before upgrading.

I have to say, as much as I like and respect you guys, that I'm also - like another poster here mentioned - starting to seriously get the impression that virtualmin is suffering as cloudmin is being developed. Before Cloudmin, Virtualmin upgrades did not make me semi-nervous and I didn't used to hold off running upgrades until after I could see how buggy they might be by reading other clients reactions to them here on the issue tracker. :/

R.

Rogi - I wouldn't be too worried, as this bug likely only causes a bogus cron email to be generated. It's not a show-stopper bug to be worried about. In fact, the 3.71 Virtualmin release is mainly a bugfix, so should have fewer problems than normal.

In my experience, the biggest cause of bugs in the development of new features, so even if we were putting all our effort into Cloudmin (which isn't the case), the result would actually be fewer bugs :-)

Joe's picture
Submitted by Joe on Wed, 07/29/2009 - 01:01 Pro Licensee

Does the above mean that there is going to be a 'fixed upgrade' for the latest upgrade?

Is this problem effecting your particular installation? This is not an "effects everyone" issue, and it is not at all a stability or security issue. It's cronjob error report.

I'm not sure why you would think this kind of error should prevent you from upgrading...this release is predominantly a security update for several Install Scripts. If you aren't upgrading, you could be running a half dozen insecure PHP applications.

If this issue is effecting you, then you should make the change in the file Jamie mentioned.

I have to say, as much as I like and respect you guys, that I'm also - like another poster here mentioned - starting to seriously get the impression that virtualmin is suffering as cloudmin is being developed.

3.71 is predominantly a bugfix release. It has fewer bugs than 3.70.

Before Cloudmin, Virtualmin upgrades did not make me semi-nervous and I didn't used to hold off running upgrades until after I could see how buggy they might be by reading other clients reactions to them here on the issue tracker. :/

We've always had new bugs in every release. I don't understand why you're suddenly superstitious about upgrades. ;-)

The other user you're speaking of has system problems unrelated to Virtualmin. He very frequently complains, and always has (we've known him for several years now). We love him, as we love all of our customers, but some users are more superstitious about the causes of problems than others; you may note that he has filed no tickets with specific problem reports...he's just venting about various frustrations, which are, as far as I can tell, not actually related to Virtualmin at all (we'll see, we've asked for more specific information about the problems he's having; if they are Virtualmin bugs they will be fixed). Do not let superstitions stand in the way of running the latest, most secure, and most stable release of Virtualmin. If there are problems in this release, or any other, we will fix them.

jezdez - thanks for that mail log. I have found the underlying problem, and will include a fix in the next Virtualmin release so that Dovecot mail logs are properly included in bandwidth counts.

"If you aren't upgrading, you could be running a half dozen insecure PHP applications."

Hello Joe,

I am not running any insecure apps, let alone half a dozen, and I do not rely on VM to keep my servers, nor any scripts running on them, up to date/secure.

"We've always had new bugs in every release. I don't understand why you're suddenly superstitious about upgrades."

Possibly because the last one took down servers? That sort of thing tends to bring out the superstitious side of people's nature. These things happen, sure, and are just a part of normal life (and a not terribly important part at that), but after they do happen confidence in the scripts that cause them, like the servers themselves, takes a while to rebuild.

As for the rest, yes, I understood the that other poster was a little 'enthusiastic' as regards his point of view re. the state of VM. However, his 'enthusiasm' does not mean that he was entirely 100% wrong, and in any case, my (small) concern is/was mine alone, and is/was not based upon the opinions of anyone else.

I had already read Jamie's reply before you posted yours above, and I'm happy with his reply (as is usually the way).

R.

Joe's picture
Submitted by Joe on Wed, 07/29/2009 - 01:51 Pro Licensee

Possibly because the last one took down servers?

OK, yeah, that was stupid. If it makes you feel any better, it only effected a handful of users. (It probably won't make you feel better if you were among that handful.) ;-)

In that particular case, the release was rushed because of security issues that needed to be corrected quickly. This led to less testing than usual, and no time for Virtualmin GPL users to bang on it before rolling out to Professional repos (they rolled simultaneously, because the release notes included information about the security issues).

Anyway, we test releases more today, both via automated tests and via human QC testing, than ever before, and we make changes with more care than ever before, because we have a lot more users than even this time last year.

But, if you aren't running any Install Scripts installed applications, then you can take your time upgrading, if you like, as long as we don't mention any security issues in Virtualmin itself in the release notes (which has only happened maybe two or three times in the entire six year history of Virtualmin, so it's pretty rare).

"OK, yeah, that was stupid. If it makes you feel any better, it only effected a handful of users. (It probably won't make you feel better if you were among that handful.) ;-)"

Hey Joe (as Jimi Hendrix once famously remarked),

I was indeed one of the lucky handful.

I think that you saying that it was 'stupid' is overly harsh. It was just a mistake, and they happen. It was also a great example of how a really tiny mistake can cause complete chaos, and considering how small that bad line was, and how much code VM/WM contains, it's really a miracle that sort of thing doesn't happen every five minutes. ;)

So no worries, I wasn't complaining - I'm happy with VM - I was just pointing out why I was a bit more 'superstitious' as regards this update than usual. You did ask, after all. ;)

R.