[DEBIAN]NIC met statisch IP vraagt DHCP om een dynamisch IP.

[van.der.schulting]

Zaterdagmiddag om 12.29 uur reageerde volgens de monitoring-server een van de productie-servers niet meer. Het bleek dat een netwerkinterface down was. Met het commando 'ifup eth0' was het probleem zo verholpen.

Uit de /var/log/syslog haal ik het volgende:

code:

Nov 12 12:28:49 prod-app01 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
Nov 12 12:28:57 prod-app01 kernel: [435194.803045] iptables denied: IN=eth1 OUT= MAC=00:0c:29:7f:d9:76:c4:3d:c7:7b:e4:eb:08:00 SRC=192.168.3.1 DST=192.168.3.20 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=38029 DPT=137 LEN=58
Nov 12 12:29:01 prod-app01 dhclient: No DHCPOFFERS received.
Nov 12 12:29:01 prod-app01 dhclient: No working leases in persistent database - sleeping.

Hierin wordt duidelijk bevestigt dat eth0 down was. Echter heeft eth0 een statisch IP. Dit blijkt uit de config-file '/etc/network/interfaces':

code:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
auto eth0
auto eth1
iface lo inet loopback

# The primary network interface
#allow-hotplug eth0
iface eth0 inet static
    address 192.168.2.20
    netmask 255.255.255.0
    network 192.168.2.0
    broadcast 192.168.1.255
    gateway 192.168.2.1
    # dns-* options are implemented by the resolvconf package, if installed

iface eth1 inet static
    address 192.168.3.20
    netmask 255.255.255.0
    network 192.168.3.0
    broadcast 192.168.3.255
    gateway 192.168.3.1
    # dns-* options are implemented by the resolvconf package, if installed

Zoals ik het in mijn logfile lees, doet eth0 iets wat hij helemaal niet zou moeten doen: Een dynanmisch IP opvragen, terwijl hij een statisch IP heeft...??
Wie kan mij uitleggen hoe dit heeft kunnen gebeuren of waar moet ik het probleem zoeken?

Ik snap het niet en heb geen idee waar ik het probleem moet zoeken.

[benoni]

Heeft ie misschien een probleem met het uitlezen van /etc/network/interfaces?

Ik heb wel eens gezien dat een config bestand vanuit Windows was aangemaakt en dat het niet goed werd geparsed vanwege de regeleindes.

[van.der.schulting]

Niet dat ik weet, kan daarover niets terugvinden in de logfiles. Wel zie ik nu dat eth1 hetzelfde gedaan heeft 1,5 minuut eerder.

code:

Nov 12 12:27:24 prod-app01 dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 6
Nov 12 12:27:30 prod-app01 dhclient: No DHCPOFFERS received.
Nov 12 12:27:30 prod-app01 dhclient: No working leases in persistent database - sleeping.

Nadat ik even verder heb gezocht zie ik het nu veel vaker voorkomen; een DHCPDISCOVER melding. Bijvoorbeeld:

code:

Nov 12 12:55:25 prod-app01 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5

Wat houdt die DHCPDISCOVER in? Alles staat op statisch IP en dat gaat al weken prima... behalve afgelopen zaterdag dan voor eth0

[benoni]

Mmm.... als je zelf ifup doet dan leest ie de config gewoon goed uit begrijp ik (als je daarna met ifconfig kijkt, zie je dat hij netjes op het vaste IP zit). Maar op een gegeven moment gaat ie uit zichzelf opnieuw de interface instellen met een dhcp configuratie. Of in ieder geval is er op 12 november zoiets gebeurd.

Draait er misschien een wifi daemon en/of een network manager in een gebruikersomgeving (lijkt me iets wat je eerder op een laptop zou verwachten, maar je weet maar nooit)?

[van.der.schulting]

Het is een Debian installatie op VMWare ESX (virtualisatie dus ). ESX draait op een professionele machine (HP DL180 G6). Geen Wifi oid, De machine heeft alleen 2 hardwarematige nics.
Binnen ESX zijn 2 virtuele netwerken gedefinieerd. Elk virtueel netwerk is aangesloten op 1 van de 2 nics.
De Debian installatie is weer aangesloten op beide virtuele netwerken via 2 virtuele nics (eth0 en eth1).

De enige netwerk manager die ik geinstalleerd heb is 'iftop'.

[CyBeR]

Heb je dat ding niet gewoon ooit op dhcp ingesteld en niet gereboot sinds je 'm naar static hebt gezet? De dhcp client is namelijk gewoon een daemon in de achtergrond die in dat geval volgens mij niet afgeschoten wordt.

pkill dhclient

[deadinspace]

van.der.schulting schreef op maandag 14 november 2011 @ 11:10:
Zaterdagmiddag om 12.29 uur reageerde volgens de monitoring-server een van de productie-servers niet meer. Het bleek dat een netwerkinterface down was. Met het commando 'ifup eth0' was het probleem zo verholpen.

Dat is interessant, dan lijkt het er op dat iets ifdown gedaan heeft. Als je namelijk twee keer ifup op een interface doet, dan krijg je de melding: "ifup: interface eth0 already configured".

Uit de /var/log/syslog haal ik het volgende:
[code]
Nov 12 12:28:49 prod-app01 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12

Er draait dus een dhcp client voor eth0, dat is zeker niet de bedoeling als eth0 statisch geconfigureerd is.

Hierin wordt duidelijk bevestigt dat eth0 down was. Echter heeft eth0 een statisch IP. Dit blijkt uit de config-file '/etc/network/interfaces': [...]

Het broadcast adres voor eth0 in je config klopt niet (maar dat zal niet gerelateerd zijn aan dit probleem). Je kunt network en broadcast trouwens weglaten, die kan ifupdown zelf afleiden van het IP-adres en het netmask.

benoni schreef op maandag 14 november 2011 @ 12:28:
Heeft ie misschien een probleem met het uitlezen van /etc/network/interfaces?

Kan geen kwaad om te controleren, maar als dat het geval was zou ik verwachten dat ifupdown gaat klagen, en niet dat hij in plaats daarvan maar gaat DHCPen

van.der.schulting schreef op maandag 14 november 2011 @ 14:09:
Wat houdt die DHCPDISCOVER in?

DHCPDISCOVER is een adresverzoek naar enige aanwezige DHCP-server. Het betekent dat je server actief probeert te DHCPen.

Alles staat op statisch IP en dat gaat al weken prima... behalve afgelopen zaterdag dan voor eth0

Is er zaterdag (of kort daarvoor) iets veranderd? Configuratiewijzigingen? Software geinstalleerd? Geupdate? Gereboot? Netwerkbekabeling omgegooid? VM gesuspend? Grafisch ingelogd geweest (zie hieronder)?

benoni schreef op maandag 14 november 2011 @ 14:32:
Draait er misschien een wifi daemon en/of een network manager in een gebruikersomgeving (lijkt me iets wat je eerder op een laptop zou verwachten, maar je weet maar nooit)?

Dat is een van de meest voor de hand liggende redenen inderdaad. Standaard bij een desktop setup krijg je network-manager mee, en die negeert wat ifupdown doet en doet zijn eigen dingen. Dat kan inderdaad tot dit soort situaties leiden.

van.der.schulting, kun je de output van

ps auxf

geven?

CyBeR schreef op maandag 14 november 2011 @ 15:30:
Heb je dat ding niet gewoon ooit op dhcp ingesteld en niet gereboot sinds je 'm naar static hebt gezet? De dhcp client is namelijk gewoon een daemon in de achtergrond die in dat geval volgens mij niet afgeschoten wordt.

Dat klopt, en dat is inderdaad een andere mogelijkheid. De juiste manier om dat te doen is dan ook: ifdown eth0, config aanpassen, ifup eth0. Dan onstaat dat probleem niet.

pkill dhclient

Zeg dat nou niet! Zolang die dhclient nog draait hebben we nog een kans er achter te komen waar hij vandaan komt, als je hem afschiet dan is het gokken.

[CyBeR]

deadinspace schreef op maandag 14 november 2011 @ 20:54:
[...]

Zeg dat nou niet! Zolang die dhclient nog draait hebben we nog een kans er achter te komen waar hij vandaan komt, als je hem afschiet dan is het gokken.

Dat is pas interessant als 'ie na een reboot terugkomt.

[deadinspace]

CyBeR schreef op maandag 14 november 2011 @ 21:23:
Dat is pas interessant als 'ie na een reboot terugkomt.

Niet mee eens. Er is nu iets mis, dus het is ook nu interessant om te weten waar hij vandaan komt.

[CyBeR]

deadinspace schreef op maandag 14 november 2011 @ 21:42:
[...]

Niet mee eens. Er is nu iets mis, dus het is ook nu interessant om te weten waar hij vandaan komt.

In de meeste productie-omgevingen is het niet interessant om een eenmalige en simpel op te lossen fout tot in de puntjes te gaan onderzoeken. Dat kost tijd en dus geld en onderwijl is die bak nog altijd stuk (of in dit geval loopt 'ie een extra groot risico weer stuk te gaan).

Als het nog een keer gebeurt dan is 't absoluut de moeite waard om wat tijd te investeren in het achterhalen van het probleem; maar bij een eenmalig probleem wat veroorzaakt is door een menselijke fout (en zo ziet het er hier uit) is dat gewoon niet zo.

[deadinspace]

CyBeR schreef op maandag 14 november 2011 @ 21:53:
In de meeste productie-omgevingen is het niet interessant om een eenmalige en simpel op te lossen fout tot in de puntjes te gaan onderzoeken.

Daar ben ik het niet mee eens. Als de oorzaak niet bekend is, dan weet je dus niet of het in de toekomst weer gaat gebeuren, en zo ja wanneer. Dat kan ook weer geld kosten in productie. Dat is natuurlijk een kosten-baten afweging, maar ik geef de voorkeur aan fatsoenlijk fixen.

Dat kost tijd en dus geld en onderwijl is die bak nog altijd stuk (of in dit geval loopt 'ie een extra groot risico weer stuk te gaan).

Misschien, maar dat is dan een afweging voor van.der.schulting.

Door gewoon maar "pkill dhclient" te roepen bestaat de kans dat hij dat gewoon uitvoert en daarna pas er achter komt dat dat het achterhalen van de oorzaak lastiger maakt. Mensen moeten eigenlijk niet klakkeloos commando's copy/pasten zonder na te denken natuurlijk, maar dat gebeurt wel. Ik ben daarom geen fan van dat soort adviezen. In ieder geval niet zonder de waarschuwing dat dat het achterhalen van de oorzaak moeilijker maakt.

Bovendien kun je ook eerst nog wat forensische info opslaan (zoals mijn ps auxf, welke al veel waardevolle informatie kan geven) voordat je die dhclient om legt.

... een eenmalig probleem wat veroorzaakt is door een menselijke fout (en zo ziet het er hier uit) ...

Dat vind ik een voorbarige conclusie. Merk op dat hij postte dat het wekenlang goed gegaan is en nu ineens fout gaat. Als het de suggestie uit je vorige post betreft dan zou ik eigenlijk verwachten dat het eerder dan na een paar weken fout gaat.

[ Voor 5% gewijzigd door deadinspace op 14-11-2011 22:14 ]

[van.der.schulting]

Zaterdag is er niet geklust aan de server oid.
Het enige dat vrijdagmiddag aangepast zou kunnen zijn de iptables.

Ik durf niet te zeggen of het statische IP is ingesteld voor de laatste reboot.
Hoewel ik de server wel zou kunnen rebooten, doe ik dat liever niet. Het is een productiemachine en als er tijdens de reboot iets misgaat ben ik verder van huis.

pkill dclient klonk mij opzich goed in de oren. Voordat ik dat echter doe wacht ik, zoals eerder aangegeven, liever eerst even af of dit euvel nog een keer voorkomt. Wellicht dat in dat geval een reboot ook een goede optie is.

@deadinspace, kun je iets met ps auxf

Resultaat ps auxf

code:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0      0     0 ?        S    Nov07   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Nov07   0:01  \_ [migration/0]
root         4  0.0  0.0      0     0 ?        S    Nov07   0:09  \_ [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [watchdog/0]
root         6  0.0  0.0      0     0 ?        S    Nov07   0:01  \_ [migration/1]
root         7  0.0  0.0      0     0 ?        S    Nov07   0:26  \_ [ksoftirqd/1]
root         8  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [watchdog/1]
root         9  0.0  0.0      0     0 ?        S    Nov07   0:01  \_ [migration/2]
root        10  0.0  0.0      0     0 ?        S    Nov07   0:31  \_ [ksoftirqd/2]
root        11  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [watchdog/2]
root        12  0.0  0.0      0     0 ?        S    Nov07   0:01  \_ [migration/3]
root        13  0.0  0.0      0     0 ?        S    Nov07   0:48  \_ [ksoftirqd/3]
root        14  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [watchdog/3]
root        15  0.0  0.0      0     0 ?        S    Nov07   0:03  \_ [events/0]
root        16  0.0  0.0      0     0 ?        S    Nov07   0:03  \_ [events/1]
root        17  0.0  0.0      0     0 ?        S    Nov07   0:03  \_ [events/2]
root        18  0.0  0.0      0     0 ?        S    Nov07   0:05  \_ [events/3]
root        19  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [cpuset]
root        20  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [khelper]
root        21  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [netns]
root        22  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [async/mgr]
root        23  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [pm]
root        24  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [sync_supers]
root        25  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [bdi-default]
root        26  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kintegrityd/0]
root        27  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kintegrityd/1]
root        28  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kintegrityd/2]
root        29  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kintegrityd/3]
root        30  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kblockd/0]
root        31  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kblockd/1]
root        32  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kblockd/2]
root        33  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kblockd/3]
root        34  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kacpid]
root        35  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kacpi_notify]
root        36  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kacpi_hotplug]
root        37  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kseriod]
root        42  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kondemand/0]
root        43  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kondemand/1]
root        44  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kondemand/2]
root        45  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kondemand/3]
root        46  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [khungtaskd]
root        47  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kswapd0]
root        48  0.0  0.0      0     0 ?        SN   Nov07   0:00  \_ [ksmd]
root        49  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [aio/0]
root        50  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [aio/1]
root        51  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [aio/2]
root        52  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [aio/3]
root        53  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [crypto/0]
root        54  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [crypto/1]
root        55  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [crypto/2]
root        56  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [crypto/3]
root       280  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ata/0]
root       281  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ata/1]
root       282  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ata/2]
root       283  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ata/3]
root       284  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ata_aux]
root       286  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [scsi_eh_0]
root       287  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [scsi_eh_1]
root       291  0.0  0.0      0     0 ?        S    Nov07   0:04  \_ [mpt_poll_0]
root       292  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [mpt/0]
root       298  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [scsi_eh_2]
root       328  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kstriped]
root       338  0.0  0.0      0     0 ?        S    Nov07   1:00  \_ [kjournald]
root       669  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [kpsmoused]
root       847  0.0  0.0      0     0 ?        S    Nov07   0:02  \_ [kdmflush]
root       876  0.0  0.0      0     0 ?        S    Nov07   0:11  \_ [jbd2/dm-0-8]
root       877  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ext4-dio-unwrit]
root       878  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ext4-dio-unwrit]
root       879  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ext4-dio-unwrit]
root       880  0.0  0.0      0     0 ?        S    Nov07   0:00  \_ [ext4-dio-unwrit]
root       904  0.0  0.0      0     0 ?        S    Nov07   0:23  \_ [flush-8:0]
root       905  0.0  0.0      0     0 ?        S    Nov07   0:05  \_ [flush-254:0]
root         1  0.0  0.0   8352   732 ?        Ss   Nov07   0:08 init [2]  
root       470  0.0  0.0  16868   392 ?        S<s  Nov07   0:00 udevd --daemon
root      2317  0.0  0.0  16864   268 ?        S<   Nov07   0:00  \_ udevd --daemon
root      2318  0.0  0.0  16864   228 ?        S<   Nov07   0:00  \_ udevd --daemon
root      2291  0.0  0.0 120220  1492 ?        Sl   Nov07   0:21 /usr/sbin/rsyslogd -c4
root      2332  0.0  0.0  54564   464 ?        Ss   Nov07   0:00 /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root      2334  0.0  0.0  54564   164 ?        S    Nov07   0:00  \_ /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root      2335  0.0  0.0  54564    52 ?        S    Nov07   0:00  \_ /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root      2336  0.0  0.0  54564    52 ?        S    Nov07   0:00  \_ /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root      2337  0.0  0.0  54564    52 ?        S    Nov07   0:00  \_ /usr/sbin/saslauthd -a pam -c -m /var/run/saslauthd -n 5
root      2342  0.0  0.0   3916   508 ?        Ss   Nov07   0:00 /usr/sbin/acpid
root      2375  0.0  0.1  81908  4080 ?        Ss   Nov07   0:11 /usr/sbin/apache2 -k start
root     31372  0.0  0.0  23424  1940 ?        Ssl  Nov13   0:00  \_ PassengerWatchdog
root     31375  0.0  0.0 164168  2948 ?        Sl   Nov13   1:30  |   \_ PassengerHelperAgent
root     31377  0.0  0.2  41632  9892 ?        Sl   Nov13   1:48  |   |   \_ Passenger spawn server                                                           
nobody   31382  0.0  0.0  74660  3956 ?        Sl   Nov13   0:00  |   \_ PassengerLoggingAgent
www-data 31389  0.0  0.0  82056  3308 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data 31391  0.0  0.0  82064  3344 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data  5157  0.0  0.0  82064  3228 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data  5203  0.0  0.0  82176  3232 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data  5210  0.0  0.0  82176  3364 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data  6627  0.0  0.0  82176  3296 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data  6663  0.0  0.0  82176  3212 ?        S    Nov13   0:00  \_ /usr/sbin/apache2 -k start
www-data 17479  0.0  0.0  82176  3372 ?        S    Nov14   0:00  \_ /usr/sbin/apache2 -k start
www-data 18148  0.0  0.0  82176  3128 ?        S    Nov14   0:00  \_ /usr/sbin/apache2 -k start
www-data  1794  0.0  0.0  81908  2148 ?        S    00:19   0:00  \_ /usr/sbin/apache2 -k start
nagios    2450  0.0  0.0  24692   692 ?        Ss   Nov07   0:38 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -d
104       2506  0.0  0.0  23260   380 ?        Ss   Nov07   0:00 /usr/bin/dbus-daemon --system
redis     2513  0.0  0.0   7628  1240 ?        Ss   Nov07   2:01 /usr/bin/redis-server /etc/redis/redis.conf
root      2514  0.0  0.0  22420   908 ?        Ss   Nov07   0:02 /usr/sbin/cron
root      2521  0.1  0.5 197056 21124 ?        Sl   Nov07  12:52 /usr/local/bin/ruby /usr/local/bin/god -c /rails/scrapers_v1/current/config/god.config
root      2557  0.0  0.0  37160  2108 ?        Ss   Nov07   0:06 /usr/lib/postfix/master
postfix   4057  0.0  0.0  39384  2528 ?        S    Nov13   0:02  \_ qmgr -l -t fifo -u
postfix  17666  0.0  0.0  41744  3396 ?        S    Nov14   0:00  \_ tlsmgr -l -t unix -u -c
postfix   2697  0.0  0.0  39468  3052 ?        S    11:13   0:00  \_ local -t unix
postfix   5220  0.0  0.0  39236  2368 ?        S    11:37   0:00  \_ trivial-rewrite -n rewrite -t unix -u -c
postfix   7535  0.0  0.0  39324  2500 ?        S    11:59   0:00  \_ cleanup -z -t unix -u -c
postfix   7946  0.0  0.0  39224  2380 ?        S    12:03   0:00  \_ pickup -l -t fifo -u -c
root      2583  0.0  0.0   5928   524 tty2     Ss+  Nov07   0:00 /sbin/getty 38400 tty2
root      2584  0.0  0.0   5928   524 tty3     Ss+  Nov07   0:00 /sbin/getty 38400 tty3
root      2585  0.0  0.0   5928   524 tty4     Ss+  Nov07   0:00 /sbin/getty 38400 tty4
root      2586  0.0  0.0   5928   524 tty5     Ss+  Nov07   0:00 /sbin/getty 38400 tty5
root      2587  0.0  0.0   5928   524 tty6     Ss+  Nov07   0:00 /sbin/getty 38400 tty6
root      2677  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=ES::EbayESScraper
root      2689  0.0  2.1 798216 88156 ?        Sl   Nov07   6:57  \_ resque-1.19.0: Waiting for ES::EbayESScraper                               
root      2683  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=GLOBAL::EbayCOMScraper
root      2700  0.0  2.1 799112 89092 ?        Sl   Nov07   6:57  \_ resque-1.19.0: Waiting for GLOBAL::EbayCOMScraper                               
root      2690  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=NL::SpeurdersScraper
root      2701  0.0  2.3 865152 97072 ?        Sl   Nov07   6:39  \_ resque-1.19.0: Forked 4047 at 1321352761                                      
root      4047  0.6  2.9 898596 119980 ?       Sl   11:26   0:14      \_ resque-1.19.0: Processing NL::SpeurdersScraper since 1321352761               
root      2696  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=NL::TweedehandsNLScraper
root      2703  0.0  2.3 856208 95812 ?        Sl   Nov07   6:57  \_ resque-1.19.0: Waiting for NL::TweedehandsNLScraper                               
root      2708  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=NL::MarktplazaNLScraper
root      2719  0.0  2.1 799156 89076 ?        Sl   Nov07   6:54  \_ resque-1.19.0: Waiting for NL::MarktplazaNLScraper                               
root      2714  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=NL::KapazaNLScraper
root      2730  0.0  2.1 798704 88716 ?        Sl   Nov07   7:00  \_ resque-1.19.0: Waiting for NL::KapazaNLScraper                               
root      2721  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=NL::EbayNLScraper
root      2731  0.0  2.3 856680 94868 ?        Sl   Nov07   6:57  \_ resque-1.19.0: Waiting for NL::EbayNLScraper                               
root      2727  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:workers QUEUE=NL::MarktplaatsScraper COUNT=
root      2737  0.0  1.1 753256 44856 ?        Sl   Nov07   6:28  \_ /usr/local/bin/ruby /usr/local/bin/rake resque:workers QUEUE=NL::MarktplaatsScraper COUNT=
root      3054  0.0  2.3 855088 96492 ?        Sl   Nov07   6:41      \_ resque-1.19.0: Forked 7736 at 1321354866                                             
root      7736  1.5  2.4 868988 97900 ?        Sl   12:01   0:02      |   \_ resque-1.19.0: Processing NL::MarktplaatsScraper since 1321354866                
root      3056  0.0  2.3 854996 96120 ?        Sl   Nov07   6:41      \_ resque-1.19.0: Forked 7051 at 1321354494                                             
root      7051  1.7  2.4 870652 99052 ?        Sl   11:54   0:09          \_ resque-1.19.0: Processing NL::MarktplaatsScraper since 1321354494                
root      2735  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=BE::MarktplazaBEScraper
root      2747  0.0  2.1 799140 89076 ?        Sl   Nov07   6:59  \_ resque-1.19.0: Waiting for BE::MarktplazaBEScraper                               
root      2742  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=BE::TweedehandsBEScraper
root      2754  0.0  2.3 856204 95656 ?        Sl   Nov07   7:04  \_ resque-1.19.0: Waiting for BE::TweedehandsBEScraper                               
root      2749  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=BE::KapazaBEScraper
root      2758  0.0  2.3 856244 95468 ?        Sl   Nov07   6:53  \_ resque-1.19.0: Forked 7676 at 1321354834                                     
root      7676  0.7  2.3 871168 95172 ?        Sl   12:00   0:01      \_ resque-1.19.0: Processing BE::KapazaBEScraper since 1321354834               
root      2764  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=BE::EbayBEScraper
root      2791  0.0  2.3 855720 95780 ?        Sl   Nov07   6:44  \_ resque-1.19.0: Forked 7650 at 1321354813                                   
root      7650  1.5  2.3 866412 95212 ?        Sl   12:00   0:03      \_ resque-1.19.0: Processing BE::EbayBEScraper since 1321354813               
root      2766  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=FR::EbayFRScraper
root      2792  0.0  2.1 798184 88276 ?        Sl   Nov07   6:58  \_ resque-1.19.0: Waiting for FR::EbayFRScraper                               
root      2788  0.0  0.0   3952   592 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=IT::EbayITScraper
root      2808  0.0  2.1 798240 88388 ?        Sl   Nov07   6:57  \_ resque-1.19.0: Waiting for IT::EbayITScraper                               
root      2793  0.0  0.0   3952   592 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=UK::EbayUKScraper
root      2807  0.0  2.3 853612 94684 ?        Sl   Nov07   6:37  \_ resque-1.19.0: Forked 7632 at 1321354810                                   
root      7632  2.0  2.3 866716 96464 ?        Sl   12:00   0:04      \_ resque-1.19.0: Processing UK::EbayUKScraper since 1321354810               
root      2795  0.0  0.0   3952   596 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=ScraperError
root      2806  0.0  2.3 863316 95888 ?        Sl   Nov07   7:01  \_ resque-1.19.0: Waiting for ScraperError                               
root      2803  0.0  0.0   3952   592 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake resque:work QUEUE=DE::EbayDEScraper
root      2812  0.0  2.1 798224 88328 ?        Sl   Nov07   7:02  \_ resque-1.19.0: Waiting for DE::EbayDEScraper                               
root     15490  0.0  0.0   6748  1088 ?        Ss   Nov07   0:02 dhclient
root      4037  0.0  0.0  49168  1152 ?        Ss   Nov13   0:00 /usr/sbin/sshd
root      7969  0.2  0.0  70452  3276 ?        Ss   12:03   0:00  \_ sshd: jeroen [priv]
jeroen    7971  0.0  0.0  70452  1584 ?        S    12:03   0:00      \_ sshd: jeroen@pts/0
jeroen    7972  0.0  0.0  19296  2084 pts/0    Ss   12:03   0:00          \_ -bash
jeroen    7993  0.0  0.0  16444  1176 pts/0    R+   12:03   0:00              \_ ps auxf
root      4113  0.0  0.0   5928   620 tty1     Ss+  Nov13   0:00 /sbin/getty 38400 tty1
jeroen    1835  0.0  1.8 800672 74640 ?        Sl   00:20   0:25 Rails: /rails/scrapers_v1/current

[Thc_Nbl]

niemand deze gezien.

# The primary network interface
#allow-hotplug eth0
iface eth0 inet static
address 192.168.2.20
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.1.255


broadcast adres naar 192.168.2.255 zetten.

en je kan natuurlijk ook gewoon apt-get remove dhcp3-client doen.

[deadinspace]

van.der.schulting schreef op dinsdag 15 november 2011 @ 12:14:
Hoewel ik de server wel zou kunnen rebooten, doe ik dat liever niet. Het is een productiemachine en als er tijdens de reboot iets misgaat ben ik verder van huis.

Het is eigenlijk wel een goed idee om een keer te rebooten als dit is opgelost, en sowieso na netwerkwijzigingen, puur om te weten of alles goed terug komt na een reboot. Een reboot komt er vroeg of laat toch wel een keer aan (al is het maar door een power outage of een foutje), en dan kom je er op een vervelender moment achter dat er wat mis is

pkill dclient klonk mij opzich goed in de oren. Voordat ik dat echter doe wacht ik, zoals eerder aangegeven, liever eerst even af of dit euvel nog een keer voorkomt. Wellicht dat in dat geval een reboot ook een goede optie is.

Er schoot me nog wat te binnen: je zou ook

killall -STOP dhclient

kunnen doen. Dan wordt het proces gepauzeerd en zal hij dus niet meer je netwerk interface rommelen, maar het proces blijft nog wel bestaan zodat je het kunt inspecteren.

@deadinspace, kun je iets met ps auxf [stevig ingekort]

code:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0      0     0 ?        S    Nov07   0:00 [kthreadd]
root         1  0.0  0.0   8352   732 ?        Ss   Nov07   0:08 init [2]  
root      2291  0.0  0.0 120220  1492 ?        Sl   Nov07   0:21 /usr/sbin/rsyslogd -c4
root      2342  0.0  0.0   3916   508 ?        Ss   Nov07   0:00 /usr/sbin/acpid
104       2506  0.0  0.0  23260   380 ?        Ss   Nov07   0:00 /usr/bin/dbus-daemon --system
root      2587  0.0  0.0   5928   524 tty6     Ss+  Nov07   0:00 /sbin/getty 38400 tty6
root      2677  0.0  0.0   3952   508 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake
root      2793  0.0  0.0   3952   592 ?        Ss   Nov07   0:00 sh -c cd /rails/scrapers_v1/current && rake
root     15490  0.0  0.0   6748  1088 ?        Ss   Nov07   0:02 dhclient

Even van te voren: ik neem aan dat je Lenny (Debian 6.0) draait?

Ik heb geen harde conclusies, maar er vallen me wel een aantal dingen op:

• Er draait geen network-manager, dus die invalshoek valt af.
• De machine is up sinds Maandag 7 november, en dhclient is diezelfde dag gestart. Maar niet automatisch denk ik, zie volgende punten.
• dhclient draait zonder argumenten. Dat is vreemd, want als dhclient door ifupdown (of network-manager) gestart wordt dan gebeurt dat altijd met een handvolg argumenten, zoals dit (dhclient vanuit ifupdown op Lenny):

  dhclient -v -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0

  
  Dat suggereert dat dhclient "los" gestart is, mogelijk met de hand.
• dhclient staat vrij ver naar beneden in de processlijst, en heeft een aanzienlijk hoger PID dan alles dat tijdens het booten wordt opgestart. Ook dat duidt erop dat hij niet tijdens het booten is gestart.

Ik krijg bijna het gevoel dat die machine op 7 december is geboot, en dat even later iemand is ingelogd en "dhclient" heeft getypt. Zou dat eventueel kunnen?

Als je het niet weet, dan kun je iig nog de volgende dingen doen om iets meer duidelijkheid te krijgen:

• De start-tijden van een aantal processen (init, syslogd, dbus, rails app, dhclient) in meer detail bekijken met

  ls -ld 1 2291 2506 2793 15490

• De environment van dhclient bekijken:

  cat /proc/15490/environ

• /root/.bash_history doorzoeken op gebruik van dhclient, ifupdown, aanpassingen van /etc/network/interfaces, etc (aangenomen dat de shell van root bash is)
• Als je gisteren en vandaag /etc/network/interfaces nog niet hebt aangepast kun je kijken wanneer die file wel voor het laatst is aangepast met

  ls -l /etc/network/interfaces

Hopelijk geeft dat wat meer duidelijkheid.

Thc_Nbl schreef op dinsdag 15 november 2011 @ 13:25:
niemand deze gezien.

Jup, gezien. ZIe mijn eerste post in deze thread