Bug Reports

I switched to 1.8.1 last month.  Since then, I've had to reboot the device twice because the '/' file system fills up.  This prevents DHCP from handing out leases.  Currently it's mounting /dev/md0 which is only 19M in size.  Upon boot, it's already consuming 17M.   I know this is the virtual image and it's made to fit on smaller thumb drives, but there really should be more space on the / file system or some kind of 'maintenance task' that cleans up the databases on the / file system.


Feb 10 17:59:57 10.13.30.1 Feb 10 17:59:57 dhcpd: DHCPREQUEST for 10.13.30.192 (10.13.30.1) from 00:07:da:ce:a0:51 (IntelCE) via dc0: database update failed
Feb 10 17:59:57 10.13.30.1 Feb 10 17:59:57 dhcpd: commit_leases: unable to commit: No space left on device

I was able to pull that from my remote syslog server.

Thanks!

What I am confused about is why is your md0 so small?  Mine is 35 meg...  Go to the hidden exec.php page and type "df -h" and "top -d1" and paste the results here.

That's a very very good question.  It's not like the device in question is out of space...

ad0: 114473MB <WDC WD1200JB-00GVC0 08.02D08> at ata0-master PIO4
(Yes, I know it's a waste of a drive... but *shrug* it's a retired desktop and I don't feel like messing with it)

Code:

$ df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       19M     17M    2.1M    89%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/ad0a      13M     11M    1.5M    89%    /cf

Code:

$ top -d1
last pid: 11748;  load averages:  0.00,  0.00,  0.00  up 1+03:50:08    23:53:50
18 processes:  1 running, 16 sleeping, 1 zombie

Mem: 13M Active, 6448K Inact, 23M Wired, 52K Cache, 9104K Buf, 1811M Free
Swap:


PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
 2971 root        1  44    0  3368K  1256K select   0:06  0.00% rtadvd
  103 root        1  44    0  3396K  1364K select   0:05  0.00% syslogd
  123 root        1  44    0  3644K  2164K select   0:02  0.00% snmpd
   74 root        1  46    0  3300K  1752K select   0:01  0.00% dhclient
  108 nobody      1  44    0  3300K  1500K select   0:01  0.00% dnsmasq
   91 root        1  44    0  3300K  1780K nanslp   0:00  0.00% ipmon
  116 root        1  44    0  4324K  3424K select   0:00  0.00% dhcpd
11745 root        1  60   10 10368K  8580K piperd   0:00  0.00% php
  114 root        1  44    0  3300K  1372K nanslp   0:00  0.00% ez-ipupdate
  105 root        1  44    0  5144K  2152K select   0:00  0.00% mini_httpd
 6668 root        1  44    0  3404K  1404K nanslp   0:00  0.00% sntp
  110 root        1  44    0  3684K  1480K wait     0:00  0.00% sh
11748 root        1  60   10  3696K  1648K RUN      0:00  0.00% top
  126 root        1  44    0  6836K  3188K select   0:00  0.00% mpd5
  135 root        1  76    0  3684K  1484K ttyin    0:00  0.00% sh
 2965 root        1  76    0  3300K  1356K select   0:00  0.00% dhcp6c
11747 root        1  44    0  5144K  2204K piperd   0:00  0.00% mini_httpd

I'm seeing similar values (1.8.1 on ALIX):

$ df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       19M     17M    2.3M    89%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/ad0a      13M     11M    1.5M    89%    /cf

1.8.1 on ALIX here also. CF card is 32MB

ad0: 30MB <SanDisk SDCFB-32 Vdg 1.23> at ata0-master PIO4

$  df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       19M     17M    2.2M    89%    /
devfs              1.0k    1.0k      0B    100%    /dev
/dev/ad0a      13M     11M    1.5M    89%    /cf

Now this is odd...  From my home system, a 1.8.2b system...

Code:

$ df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       35M     17M     18M    49%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/ad0a      24M     11M     13M    48%    /cf

From a 1.8.1b540 I have in production...

Code:

$ df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       35M     35M     56k   100%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/ad4a      24M     11M     12M    48%    /cf

Note that system 2 has an uptime of 281 days...  Until today.

Upgraded to 1.8.2b570.

$  df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       35M     17M     18M    49%    /
devfs             1.0k     1.0k      0B   100%    /dev
/dev/ad0a      24M     11M     13M    48%    /cf

its a memory based file system, so while it loads from a disk, md0 is created in RAM.

the build system that makes the images takes a sum of all the stuff in the image and adds some space for logs.  I think it's around 2MB (yes really !) , so 19M with 17M used seems right.

why some peoples is 35M sounds like a bug.  How did you write your image ?  did you write it from a ISO image or direct to disk with dd/physidiskwrite ?

The dhcp server is patched to aggressively to rewrite the lease db every 5 mins instead of every 1hr to minimize disk space used.  We had reports of disk space issues a good while ago, and this patch was the solution (in 1.3x) and it seemed to solve the problem.  Is there a lot of lease activity in your environment ?

I write direct to CF with physidiskwrite. I reported to df -h summaries, one for 1.8.1 release, the other for 1.8.2b570. So if it's a bug, it's not in both versions.

I don't have that in b570.  The ISO image is around 35M size I think, due to it having the regular image included for writing to disk, which is why I wondered if it was connected.

are both you installs generic-serial ?

Both are generic-pc-serial.

As a linux geek, I use dd to write the images.  I think I am seeing a pattern in the differences.

However, I did an upgrade to 1.8b540 from 1.34 with the modified space hack from exec.php, and it is 35 meg as well.

$ df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       35M     20M     14M    58%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/ad4a      24M     11M     12M    48%    /cf


Also, I consider the 35 meg file system to be a VAST improvement.  I do not know how many times I had a critical failure when I ran out of disk space because of an unplanned change.  (Like 100 people suddenly coming in and signing up on captive portal at once)  I see it as a feature, and one I would not want to give up!

for what it is worth, I am on 1.8.1b545, generic PC.  I "think" I installed from CD using the option 7.  I've installed monowall before with dd and physidiskwrite but I think this particular instance I used the CD.  My output is below.

$ df -h
Filesystem    Size    Used   Avail Capacity  Mounted on
/dev/md0       35M     17M     18M    49%    /
devfs         1.0k    1.0k      0B   100%    /dev
/dev/ad4a      24M     11M     12M    48%    /cf

$ top -d1
last pid:  2501;  load averages:  0.02,  0.01,  0.00  up 44+21:03:47    07:51:56
16 processes:  1 running, 14 sleeping, 1 zombie

Mem: 11M Active, 5612K Inact, 30M Wired, 48K Cache, 7968K Buf, 1896M Free
Swap:


  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 2494 root        1  55   10 10360K  8528K piperd  1   0:00  0.88% php
   65 root        1  44    0  3300K  1736K select  1   0:50  0.00% dhclient
   75 root        1  44    0  3300K  1776K nanslp  0   0:47  0.00% ipmon
   84 nobody      1  44    0  3300K  1488K select  1   0:38  0.00% dnsmasq
   79 root        1  44    0  3388K  1256K select  3   0:07  0.00% syslogd
   81 root        1  45    0  5136K  2168K select  0   0:00  0.00% mini_httpd
  145 root        1  44    0  3404K  1388K nanslp  0   0:00  0.00% sntp
   86 root        1  72    0  3680K  1476K wait    3   0:00  0.00% sh
 2454 root        1  54   10  4324K  3444K select  1   0:00  0.00% dhcpd
 2501 root        1  56   10  3696K  1684K CPU2    2   0:00  0.00% top
  101 root        1  76    0  3680K  1480K ttyin   2   0:00  0.00% sh
 2495 root        1  44    0  5136K  2172K sbwait  2   0:00  0.00% mini_httpd
 2496 root        1  44    0  5136K  2172K sbwait  2   0:00  0.00% mini_httpd
 2497 root        1  44    0  5136K  2172K sbwait  2   0:00  0.00% mini_httpd
 2500 root        1  44    0  5136K  2224K piperd  0   0:00  0.00% mini_httpd

hardware:

acpi0: <INTEL D525MW> on motherboard

Mine was from CD and it's not ALIX.  It's:

CPU: AMD Athlon(tm) Processor LE-1600 (2200.01-MHz 686-class CPU)

It's a full-blown Shuttle XPC system... slightly old but perfect for being relegated to m0n0 duty

System has 2G of memory in it.

Where are you guys getting "1.8.2b570" from?  I'll gladly upgrade to it to see if it fixes this problem.  Thanks all!

1.8.2b snapshots are here:

http://m0n0.ch/wall/snapshots/1.8.2/