Hi I'm running the current release of Debian Squeeze and have just installed a new server. All packages are up to date.
The problem: Each time the cronjob /etc/webmin/quota/email.pl runs the disk quotas get disabled:
root@mail:/etc/postfix# quotaon -p /home group-Quota auf /home (/dev/sdb1) ist aus user-Quota auf /home (/dev/sdb1) ist aus
After I re-enable the quotas they will stay enabled for about 10 minutes until the cronjob runs again. The quotas become disabled when I run the email.pl manually as well.
I analyzed the source code of the perl script but I did not find any clue why this strange misbehaving error occurs. Also I don't receive e-mails when quotas are exceeded. Thus I think the email.pl script terminates at some strange point. I did not find anything in any log (checked syslog and kernel log {dmesg} ).
Any help would be very appreciated because I need to have quotas turned on and I need to have email notifications when quotas exceed.
Regards Marcus
Hi, have the same problem!! Seems to be a bug! Any ideas?
Greetings
Ben
Hmm... well, that cron job is just looking at the current quota of all the users, and sending an email to those near their limit. It doesn't make any changes to the quotas, so it seems surprising that it would cause them to stop working.
Are you by chance using a VPS? If so, do you know what type of VPS?
Also, are you certain quotas are actually working properly prior to that script running?
For example, try enabling quotas, and then running a command like this:
quota -v USERNAMEDoes that output the correct quota for that particular username?
-Eric
Thanks for your answer, but quota works correctly until the email.pl Script is executed. Then quota is turned off. I think it's a common problem with new debian servers. And it should be fixed quickly. My workaround is now to run email.pl only once a day and after that I enable and check quotas also via cron. It's definately the Script, which has a Problem... And no VPS here...
Howdy,
Well, I've tested this on both a Debian 5 and a Debian 6 system, and I can't seem to reproduce the problem you're having.
After running that email.pl script, do any new errors show up at the end of your "dmesg" output?
Also, what that script should be doing is running some commands to check the quota for each user.
Can you go into Webmin -> Servers -> Disk Quota -> Module Config -> System Configuration... and in that screen, what is "Command to check a user's quota" and "Command to check a group's quota" set to?
On my system, those are "quota -v -u" and "quota -v -g".
Then, try running those manually against one of the users on your system:
quota -v -u USERNAMEquota -v -g USERNAME
Does that correctly output the disk quota information? And are quotas still enabled afterwards?
-Eric
Hi,
first, thanks for your help!
everything works fine until the email.pl cron occurs. The quota keeps enabled, if the script doesn't run.
I think, the thread-opener and me have the problem, because it is a german environment. Maybe there is a problem in the script with this language. And we both have a new Debian 6 setup.
Again, all quota outputs are correct and it keeps working, until the script runs.. And there is no syslog or dmesg output...
It must be a script bug...
Greetings from germany
Ben
I checked it again and found an interesting thing: If i run the script manually, everything works fine, quota stays enabled. But if it runs by CRON the behaviour occurs??!!
Any idea what the difference between these run-types could be?
thanks
Howdy,
It must be a script bug...
We may be able to figure out what's going on, but if you want assistance figuring out what's wrong, you'll have to allow us to help :-)
Although I've never heard of a problem with that script causing quotas to be disabled, if it is related to the script running, that means something the script is doing is causing the problem.
And, the only thing that script does that's related to the quotas are the checking the user and group quota.
So, in order to help, we'd really need to start by seeing what commands that script is running :-)
Although it might work just fine, we'd really like to see the following:
In Webmin -> Servers -> Disk Quota -> Module Config -> System Configuration... and in that screen, what is "Command to check a user's quota" and "Command to check a group's quota" set to?
On my system, those are "quota -v -u" and "quota -v -g".
Then, try running those manually against one of the users on your system:
quota -v -u USERNAMEquota -v -g USERNAME
What output does the above show?
Although all the above may work fine, it's still part of the troubleshooting process, and knowing exactly what those have will assist us in determining what's going wrong. Thanks!
-Eric
Hi,
thanks, here is the information:
Those commands are:
quota -v -uquota -v -g
Here the output of the quota-commands (sorry output is in german):
quota -v -u USERNAME:
Dateisystemquotas für user USERNAME (uid 1005):
Dateisystem Blöcke Quota LimitGnadenfrist Dateien Quota LimitGnadenfrist
/dev/disk/by-uuid/a839af2c-0e36-489e-a899-52d67d493711
325244 524288 524288 635 0 0
quota -v -g USERNAME
Dateisystemquotas für group USERNAME (gid 1005):
Dateisystem Blöcke Quota LimitGnadenfrist Dateien Quota LimitGnadenfrist
/dev/disk/by-uuid/a839af2c-0e36-489e-a899-52d67d493711
325220 524288 524288 631 0 0
Seems ok..
Thank you for your help..
Ben
Tested it again. Scripts works fine when running it not via CRON. Maybe there is a problem in environment?
Thanks for all the info! I'm talking to Jamie about potential causes for what you're seeing, I'll let you know what we come up with.
-Eric
Howdy,
Okay, Jamie is going to check for some possible bugs that could cause that issue... but in order to do that, he needs the output of a couple of commands.
First, what does the command "mount" show on your server?
Second, what output does this show:
dmesg | tail -10With the above, I'll give you another command you can run that will allow him to try and reproduce that problem. Thanks!
-Eric
Hi Eric,
thanks for your great support..
Here is the output of mount:
/dev/sda1 on / type ext3 (rw,grpquota,errors=remount-ro,usrquota)tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
and here the dmesg output (no entries since normal boot):
[ 3.465174] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4[ 3.678816] Adding 2004984k swap on /dev/sda5. Priority:-1 extents:1 across:2004984k
[ 3.765032] EXT3 FS on sda1, internal journal
[ 3.813259] loop: module loaded
[ 4.431196] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 4.432737] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 4.433867] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 12.275022] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 15.101276] eth0: no IPv6 routers present
Thanks,
Ben
Super!
That leads to the next command...
Jamie is wondering if there could somehow be a bug in Webmin's detection of whether or not quotas are enabled. In order for him to find that out, Jamie needs the output to this command on your server:
quotaon -p /Thanks!
-Eric
First one question... this is a production system. You will not send me any commands, which will cause damage to the running system?
Howdy,
Well, not intentionally :-)
The -p parameter to quotaon just prints the current state... this is from the quotaon manpage:
-p, --print-stateInstead of turning quotas on just print state of quotas (ie. whether. quota is on or off)
So -p doesn't actually change anything, it just shows the current quota state. On my system, that outputs this:
# quotaon -p /group quota on / (/dev/sda1) is on
user quota on / (/dev/sda1) is on
If you like, you can actually run it as a non-root user... it does not require root permissions to get that information.
-Eric
Ok here it is:
group-Quota auf / (/dev/disk/by-uuid/a839af2c-0e36-489e-a899-52d67d493711) ist anuser-Quota auf / (/dev/disk/by-uuid/a839af2c-0e36-489e-a899-52d67d493711) ist an
Thanks!
How would "ist an" translate into English, would that mean "is on"?
-Eric
yeah, you are right. it means "is on". Today you're learning german ;-))
Excellent, my first German lesson :-)
I've sent the info to Jamie, he's looking into the issue now.
I'll get back with you shortly!
-Eric
It looks like there is indeed a bug -- and thanks to all the command output you've provided above, Jamie was able to figure that out. It was a problem due to the language of your system, Webmin wasn't handling it not being English properly.
This issue will be fixed in the next Webmin version.
In the meantime -- the only ways you can get around that issue are:
Set your system to use English for it's language, and then restart Webmin.
Disable that script until after the next Webmin version comes out.
Have a good one!
-Eric
Hi Eric,
thank you so much for your help and the great support! I'll disable the script until the next version will be released.
Greetings,
Ben