[Ubuntu Server] Dhcp3-server deelt geen IP-adressen meer uit

[dtech]

Op een lokaal netwerk heb ik een ubuntu 8.04 server, die onder meer dhcp en dns server is.

Nu zijn er de laatste twee weken meerdere problemen (o.a. een zelfgeschreven init-script dat ineens kapotging), stoppen met reageren op "alles" tot een reboot, dat soort spul. Er zou dus meer aan de hand kunnen zijn, maar op het moment lijkt alles weer redelijk stabiel, er is echter wel een probleem.

Sinds vanochtend ,na een reboot, krijgen computers aangesloten op het netwerk geen IP-adressen meer. Als een IP-adres vast ingesteld wordt werkt alles wel, dus het kan niet aan een brakke netwerkkabel liggen.

dhcp3-server lijkt echter gewoon te draaien, ook restarten heeft geen zin. In de configuratie is niks veranderd maar kan ik ook niks vreemds vinden.
Ook lijkt dhcp3-server wel te luisteren, getuige de output van `netstat -uap | grep bootps`

code:

udp        0      0 *:bootps                *:*                                 20869/dhcpd3

Er is echter niks te vinden in /var/log/messages of /var/log/syslog, ook niet normale DHCPEQUEST lijnen zoals je die zou verwachten.

Heeft iemand een idee waar dit aan kan liggen of waar ik verder kan zoeken?

P.S.:
Nee, een reboot heeft het probleem niet opgelost

edit:

Foutje van mijn kant, er staan wel degelijk DHCP entries in /var/log/messages, ze zien er alleen niet goed uit:
(louisa is de systeemnaam)

code:

Aug 28 18:09:30 louisa dhcpd: DHCPOFFER on 192.168.2.250 to 00:19:d1:8f:4f:a4 via vlan2
Aug 28 18:09:30 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:30 louisa dhcpd: DHCPOFFER on 192.168.0.236 to 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:30 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:30 louisa dhcpd: DHCPOFFER on 192.168.0.236 to 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:30 louisa dhcpd: commit_leases: unable to commit: No space left on device
Aug 28 18:09:30 louisa dhcpd: DHCPREQUEST for 192.168.0.236 (192.168.0.3) from 00:19:d1:8f:4f:a4 via eth0: database update failed
Aug 28 18:09:30 louisa dhcpd: DHCPREQUEST for 192.168.1.14 from 00:11:85:50:0c:ca via vlan1
Aug 28 18:09:30 louisa dhcpd: DHCPACK on 192.168.1.14 to 00:11:85:50:0c:ca via vlan1
Aug 28 18:09:35 louisa dhcpd: commit_leases: unable to commit: No space left on device
Aug 28 18:09:35 louisa dhcpd: DHCPREQUEST for 192.168.0.236 (192.168.0.3) from 00:19:d1:8f:4f:a4 via eth0: database update failed
Aug 28 18:09:36 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via vlan3
Aug 28 18:09:36 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:36 louisa dhcpd: DHCPOFFER on 192.168.0.236 to 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:37 louisa dhcpd: DHCPOFFER on 192.168.3.249 to 00:19:d1:8f:4f:a4 via vlan3
Aug 28 18:09:42 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via vlan3
Aug 28 18:09:42 louisa dhcpd: DHCPOFFER on 192.168.3.249 to 00:19:d1:8f:4f:a4 via vlan3
Aug 28 18:09:42 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:42 louisa dhcpd: DHCPOFFER on 192.168.0.236 to 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:43 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:43 louisa dhcpd: DHCPOFFER on 192.168.0.236 to 00:19:d1:8f:4f:a4 via eth0
Aug 28 18:09:43 louisa dhcpd: commit_leases: unable to commit: No space left on device
Aug 28 18:09:43 louisa dhcpd: DHCPREQUEST for 192.168.0.236 (192.168.0.3) from 00:19:d1:8f:4f:a4 via eth0: database update failed
Aug 28 18:09:44 louisa dhcpd: DHCPDISCOVER from 00:19:d1:8f:4f:a4 via vlan2
Aug 28 18:09:44 louisa dhcpd: DHCPOFFER on 192.168.2.250 to 00:19:d1:8f:4f:a4 via v

[ Voor 49% gewijzigd door dtech op 28-08-2010 18:46 ]

[Verwijderd]

Je zal iets moeten doen aan deze melding:

Aug 28 18:09:43 louisa dhcpd: commit_leases: unable to commit: No space left on device

Doe eens een df zou ik zeggen.

[ Voor 10% gewijzigd door Verwijderd op 28-08-2010 18:54 ]

[dtech]

Ongelovelijk. Dat ik moet merken dat / vol zit aan de hand van een falende dhcp server...

Maar erg bedankt in ieder geval

[Boudewijn]

Ideetje om mischien een of andere vorm van monitoring te nemen? Dan zou je er op andere wijze achter komen.

[ex87]

Verklaard wel een hoop van je problemen een volle / misschien toch is nadenken over b.v Nagios. Ik heb hier thuis alles onder verdeeld in VM's op een Xen Cloud Host en zou er niet aan moeten denken om steeds met de hand te checken hoe het eigenlijk met me systemen gaat..

[dtech]

Zeker iets om over na te denken, de huidige IT-infrastructuur gaat binnenkort (hopelijk) toch op de schop.

Iemand in de tussentijd (ik wacht op `du -sh`) enig idee waar ik schijfruimte kan opschonen? /home en /tmp staan op aparte schijven en ik heb de logfiles al opgeschoont (Ongeveer 100MB bij elkaar).
Toch geeft df nog steeds 0 available...
Sowieso vind ik het vreemd dat een min of meer standaard ubuntu servertje 32GB vol krijgt...

[Boudewijn]

En wat raars in /var


Daar staan soms heel veel .deb's opgeslagen. En /var/log met veel logs?

[dtech]

Niks verontrustends:

code:

root@louisa:/# du -sh /var/*
12M     /var/backups
35M     /var/cache
297M    /var/lib
4.0K    /var/local
0       /var/lock
384M    /var/log
17M     /var/mail
4.0K    /var/opt
3.5M    /var/run
2.1M    /var/spool
4.0K    /var/tmp
12M     /var/www
12M     /var/www-ssl
1.1M    /var/yp

Maar ook nadat ik een 30MB logbestand uit /var/log heb verwijdert geeft df nog steeds 0 available aan op /...

[dtech]

Hmm, ik kan met dd (`dd if=/dev/zero of=/output.dat -bs=1M -count=10`) gewoon een file van 10MB in / maken, dus ik denk dat df in dit geval wat achterloopt of iets dergelijks. Morgen maar even kijken of ik weer DHCP leases krijg

[Boudewijn]

384M aan logs?

Doe eens een df'je, dan zie je tenminste of je FS vol zit.

[ Voor 4% gewijzigd door Boudewijn op 28-08-2010 22:57 ]

[ex87]

dtech schreef op zaterdag 28 augustus 2010 @ 22:40:
Hmm, ik kan met dd (`dd if=/dev/zero of=/output.dat -bs=1M -count=10`) gewoon een file van 10MB in / maken, dus ik denk dat df in dit geval wat achterloopt of iets dergelijks. Morgen maar even kijken of ik weer DHCP leases krijg

Valt mij ook altijd op dat als ik heb opgeruimd df lijkt achter te lopen of misschien wordt hij pas getriggerd bij een bepaalde grootte.. Iemand die daar wat licht op kan schijnen :-)?

[Boudewijn]

Die ervaring deel ik dan niet met jullie. Wel is het zo dat een distro een bepaald percentage (standaard @ debian meen ik 5%) van het fs kan reserveren voor gebruik door root.
Zou dat wellicht hier aan de hand kunnen zijn?

[Verwijderd]

Het is een long-shot hoor, maar hoe staat het met je inodes?
Wat geeft df -i ?

[dtech]

df -i geeft 3% in use bij inodes, dat kan het dus niet zijn.
Inmiddels geeft df weer een whopping 69MB vrije ruimte aan... Zou dus kunnen dat de schijf gewoon "echt" vol zit.

[dtech]

En dit is dus waarover ik me echt verbaas:

code:

username@louisa:/$ sudo du -sh /* --exclude home --exclude media --exclude proc --exclude dev
6.3M    /bin
20M     /boot
0       /cdrom
25M     /etc
4.0K    /initrd
0       /initrd.img
103M    /lib
0       /lib64
16K     /lost+found
8.0K    /mnt
4.0K    /opt
2.5M    /root
7.6M    /sbin
4.0K    /srv
0       /sys
56K     /tmp
1.1G    /usr
507M    /var
0       /vmlinuz

Zoals jullie kunnen zien telt dat bij elkaar op tot hoogtends 2GB... nooit de 30GB die in de partition zit. Of zie ik iets over het hoofd?

[sPENKMAN]

unmount /home en /media eens en check die dirs? Wellicht dat er data "onder de mount" is weggeschreven welke je nu niet krijgt te zien.

Daarnaast zou je nu bestanden in de / welke beginnen met een . niet bij de du te zien krijgen. Hoewel onwaarschijnlijk, staan er toevallig losse grote verborgen bestanden in de root?


@ex87
Er wordt standaard inderdaad 5% gereserveerd voor als de schijf vol komt te zitten, voordat du weer wat vrij geeft moet je dus 6% vrij hebben:

Reclaim Reserved Filesystem Space

Ext3 partition contain a used space of 5% for special reasons by default. The main reason for such space is so root can log in even when the filesystem becomes 100% used. Without this option, the root user might not be able to log in to "clean up" because the system could become unstable, trying to write logs to a 100% full system for example. The other reason is to help with less fragmentation on the filesystem.

The issue with this is that hard drives are getting so big the 5% can add up to be quite a large amount of wasted space. (eg. 100 GB = 5 GB reserved). Now if you separate your filesystems to like /home for example it might be a good idea to adjust these and reclaim that wasted space. It's a safe bet to leave your / filesystem at 5% reserved just in case. Leave reserved space for filesystems containing /var and /tmp also or else you'll end up with problems.

Bron: http://wiki.archlinux.org/index.php/Ext3_Filesystem_Tips

[ Voor 64% gewijzigd door sPENKMAN op 29-08-2010 11:39 . Reden: 5% stukje toegevoegd ]

[ex87]

Boudewijn schreef op zaterdag 28 augustus 2010 @ 23:41:
Die ervaring deel ik dan niet met jullie. Wel is het zo dat een distro een bepaald percentage (standaard @ debian meen ik 5%) van het fs kan reserveren voor gebruik door root.
Zou dat wellicht hier aan de hand kunnen zijn?

Hmm dus je bedoelt dat hij dan vanaf 5% van je totale ruimte pas weer die 0 vrij geeft, dus als je b.v 7% vrij hebt, zal dit pas duidelijk worden via du?

@sPENKMAN ah bedankt voor de heldere info, maakt een hoop duidelijk.

[ Voor 6% gewijzigd door ex87 op 29-08-2010 11:40 ]

[dtech]

sPENKMAN schreef op zondag 29 augustus 2010 @ 11:22:
unmount /home en /media eens en check die dirs? Wellicht dat er data "onder de mount" is weggeschreven welke je nu niet krijgt te zien.

Goed idee, ga ik vanavond (als degene die er mee moeten werken toch niet zoveel meer doen) proberen. Vooral bij /home zou dat het kunnen verklaren.

Daarnaast zou je nu bestanden in de / welke beginnen met een . niet bij de du te zien krijgen. Hoewel onwaarschijnlijk, staan er toevallig losse grote verborgen bestanden in de root?

Nee, daar had ik gelijk op gecontroleerd. Gelukkig waren het alleen .rnd (1KiB) en .bash_history (102 bytes)

[ Voor 3% gewijzigd door dtech op 29-08-2010 12:29 ]

[dtech]

[per ongeluk geplaats bericht]

[ Voor 94% gewijzigd door dtech op 29-08-2010 12:37 ]

[Verwijderd]

hmm en is je partitie ook echt 30GB?
wellicht heb je iets van een lvm-volume erop gemaakt maar niet alle ruimte uitgegeven.

[dtech]

Uiteindelijk vandaag pas kans gezien voor flinke downtime.

Het probleem was inderdaad dat er dingen onder de mount weggeschreven waren terwijl het device niet gemount was => op de / partitie! Bedankt!

Een backup van 27GB (en een gefaalde bij ongeveer 1,1GB) was weggeschreven. Na het verwijderen daarvan via een live-cd zijn er weer normale waarden bij df.

Het heeft misschien iets te maken met dat de livecd aangaf "SMART error: device {device-id van /dev/sde} is about to fail!" dus ik ga die snel vervangen.