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.
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 USERNAME
Does that output the correct quota for that particular username?
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…
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 USERNAME
quota -v -g USERNAME
Does that correctly output the disk quota information? And are quotas still enabled afterwards?
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…
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?
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 USERNAME
quota -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!
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 -10
With the above, I’ll give you another command you can run that will allow him to try and reproduce that problem. Thanks!
/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
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:
group-Quota auf / (/dev/disk/by-uuid/a839af2c-0e36-489e-a899-52d67d493711) ist an
user-Quota auf / (/dev/disk/by-uuid/a839af2c-0e36-489e-a899-52d67d493711) ist an
