[SOLVED] Disk quotas are being turned off upon email.pl cronjob run

22 posts / 0 new
Last post
#1 Wed, 06/08/2011 - 18:22
lexo_ch

[SOLVED] Disk quotas are being turned off upon email.pl cronjob run

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

Fri, 08/19/2011 - 04:41
BenP

Hi, have the same problem!! Seems to be a bug! Any ideas?

Greetings

Ben

Fri, 08/19/2011 - 08:05
andreychek

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?

-Eric

Sat, 08/20/2011 - 03:47
BenP

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...

Sat, 08/20/2011 - 07:56
andreychek

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 USERNAME
quota -v -g USERNAME

Does that correctly output the disk quota information? And are quotas still enabled afterwards?

-Eric

Mon, 08/22/2011 - 06:31
BenP

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

Mon, 08/22/2011 - 09:36 (Reply to #6)
BenP

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

Mon, 08/22/2011 - 10:13
andreychek

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 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!

-Eric

Mon, 08/22/2011 - 10:24 (Reply to #8)
BenP

Hi,

thanks, here is the information:

Those commands are:

quota -v -u
quota -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

Mon, 08/22/2011 - 12:14
BenP

Tested it again. Scripts works fine when running it not via CRON. Maybe there is a problem in environment?

Mon, 08/22/2011 - 13:15
andreychek

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

Mon, 08/22/2011 - 14:02
andreychek

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 -10

With the above, I'll give you another command you can run that will allow him to try and reproduce that problem. Thanks!

-Eric

Mon, 08/22/2011 - 14:44
BenP

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

Mon, 08/22/2011 - 14:50
andreychek

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

Mon, 08/22/2011 - 14:52
BenP

First one question... this is a production system. You will not send me any commands, which will cause damage to the running system?

Mon, 08/22/2011 - 15:03
andreychek

Howdy,

Well, not intentionally :-)

The -p parameter to quotaon just prints the current state... this is from the quotaon manpage:

       -p, --print-state
              Instead 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

Mon, 08/22/2011 - 15:47
BenP

Ok here it is:

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
Mon, 08/22/2011 - 16:04
andreychek

Thanks!

How would "ist an" translate into English, would that mean "is on"?

-Eric

Mon, 08/22/2011 - 16:20
BenP

yeah, you are right. it means "is on". Today you're learning german ;-))

Mon, 08/22/2011 - 16:28
andreychek

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

Tue, 08/23/2011 - 13:22
andreychek

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:

  1. Set your system to use English for it's language, and then restart Webmin.

  2. Disable that script until after the next Webmin version comes out.

Have a good one!

-Eric

Tue, 08/23/2011 - 13:31
BenP

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