Hoge load; kan niet rebooten

[Startups]

Ik draai dus een servertje (Fedora)
Korte specs: p4, 512mb
Controle paneel: DirectAdmin

Het probleem: load is aan het stijgen en hij wilt niet rebooten.
Toen ik het ontdekte was de load 6.0 nu inmiddels 8.0, normale load is altijd onder de 1 omdat ik bijna geen sites er op draai..

Gegooglet > niets gevonden
DirectAdmin Forums > gevonden, maar geen reactie die het oplost.

reactie >uptime
23:21:01 up 11 days, 9:18, 1 user, load average: 8.00, 7.94, 7.38

reactie >top

PHP:

top - 23:21:51 up 11 days,  9:19,  1 user,  load average: 8.00, 7.95, 7.41
Tasks: 154 total,   1 running, 153 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3% us,  0.3% sy,  0.0% ni, 99.3% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    452140k total,   330932k used,   121208k free,    27752k buffers
Swap:  1048816k total,     2576k used,  1046240k free,   188716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12989 root      16   0  2780  960 1620 R  0.3  0.2   0:00.13 top
    1 root      16   0  2640  456 1316 S  0.0  0.1   0:05.08 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.09 ksoftirqd/0
    3 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 events/0
    4 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
    6 root      13 -10     0    0    0 S  0.0  0.0   0:00.00 khelper
    5 root      15   0     0    0    0 S  0.0  0.0   0:00.00 khubd
    7 root      15   0     0    0    0 S  0.0  0.0   0:01.05 pdflush
    8 root      15   0     0    0    0 S  0.0  0.0   0:00.58 pdflush
   10 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
    9 root      15   0     0    0    0 S  0.0  0.0   0:01.29 kswapd0
  114 root      22   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
  148 root      15   0     0    0    0 S  0.0  0.0   0:25.05 kjournald
 1456 root      16   0  2812  588 1296 S  0.0  0.1   0:01.63 syslogd
 1460 root      16   0  2176  456 1244 S  0.0  0.1   0:00.02 klogd
 1551 root      16   0  2896  760 1368 S  0.0  0.2   0:00.01 smartd
 1560 root      18   0  1836  464 1236 S  0.0  0.1   0:00.00 acpid
 1604 root      16   0  2360  896 1684 S  0.0  0.2   0:00.00 xinetd
 1613 root      16   0  2568  956 2236 S  0.0  0.2   0:00.06 da-popb4smtp
 1622 nobody    16   0  4292 1048 3856 S  0.0  0.2   0:00.64 directadmin
 1636 mail      16   0  7632 1904 6244 S  0.0  0.4   0:00.18 exim
 1697 ftp       16   0  2260 1172 1748 S  0.0  0.3   0:00.44 proftpd
 1707 root      16   0  1676  560 1364 S  0.0  0.1   0:00.13 vm-pop3d
 1727 root      16   0  2328  652 1356 S  0.0  0.1   0:00.67 crond
 1735 root      18   0  4788 1016 3948 S  0.0  0.2   0:00.01 mysqld_safe
 1766 daemon    16   0  2488  564 1348 S  0.0  0.1   0:00.00 atd
 1772 mysql     16   0 32444 9.8m 3912 S  0.0  2.2   0:02.20 mysqld
 1782 root      16   0  2712  344 1292 S  0.0  0.1   0:00.00 mdadm
 1799 root      17   0  3072  284 1232 S  0.0  0.1   0:00.00 mingetty
 1800 root      17   0  3356  284 1232 S  0.0  0.1   0:00.00 mingetty
 1801 root      17   0  2092  284 1232 S  0.0  0.1   0:00.00 mingetty
 1802 root      18   0  2392  284 1232 S  0.0  0.1   0:00.00 mingetty
 1803 root      18   0  2348  284 1232 S  0.0  0.1   0:00.00 mingetty

En als ik probeer te rebooten, zegt hij dat hij gaat rebooten, maar doet het vervolgens niet..

Uptime inmiddels:
23:36:00 up 11 days, 9:33, 1 user, load average: 8.00, 8.00, 7.75

Dus hij blijft nu op 8.0 lijkt het..

Nog slimme tweakers die het hebben meegemaakt of die suggesties hebben?

[Jazzy]

Ik zou proces 1772 een killen als ik jou was.

[Startups]

done

PHP:

top - 23:42:27 up 11 days,  9:40,  1 user,  load average: 8.07, 8.03, 7.84
Tasks: 148 total,   1 running, 146 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.3% us,  0.7% sy,  0.0% ni, 99.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    452140k total,   331496k used,   120644k free,    28368k buffers
Swap:  1048816k total,      516k used,  1048300k free,   192284k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13319 root      16   0  2300  956 1620 R  0.7  0.2   0:00.29 top
11685 apache    15   0 19384  11m  14m S  0.3  2.7   0:00.62 httpd
12928 root      16   0  8840 2188 6844 S  0.3  0.5   0:00.11 sshd
    1 root      16   0  2640  456 1316 S  0.0  0.1   0:05.08 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.09 ksoftirqd/0
    3 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 events/0
    4 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
    6 root      13 -10     0    0    0 S  0.0  0.0   0:00.00 khelper
    5 root      15   0     0    0    0 S  0.0  0.0   0:00.00 khubd
    7 root      15   0     0    0    0 S  0.0  0.0   0:01.05 pdflush
    8 root      15   0     0    0    0 S  0.0  0.0   0:00.58 pdflush
   10 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
    9 root      15   0     0    0    0 S  0.0  0.0   0:01.29 kswapd0
  114 root      22   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
  148 root      15   0     0    0    0 S  0.0  0.0   0:25.07 kjournald
 1456 root      16   0  2812  588 1296 S  0.0  0.1   0:01.63 syslogd
 1460 root      16   0  2176  456 1244 S  0.0  0.1   0:00.02 klogd
 1551 root      16   0  2896  760 1368 S  0.0  0.2   0:00.01 smartd
 1560 root      18   0  1836  464 1236 S  0.0  0.1   0:00.00 acpid
 1604 root      16   0  2360  896 1684 S  0.0  0.2   0:00.00 xinetd
 1613 root      16   0  2568  956 2236 S  0.0  0.2   0:00.06 da-popb4smtp
 1622 nobody    15   0  4292 1048 3856 S  0.0  0.2   0:00.64 directadmin
 1636 mail      16   0  7632 1904 6244 S  0.0  0.4   0:00.18 exim
 1697 ftp       16   0  2260 1172 1748 S  0.0  0.3   0:00.44 proftpd
 1707 root      16   0  1676  560 1364 S  0.0  0.1   0:00.13 vm-pop3d
 1727 root      16   0  2328  652 1356 S  0.0  0.1   0:00.68 crond
 1766 daemon    16   0  2488  564 1348 S  0.0  0.1   0:00.00 atd
 1782 root      16   0  2712  344 1292 S  0.0  0.1   0:00.00 mdadm
 1799 root      17   0  3072  284 1232 S  0.0  0.1   0:00.00 mingetty
 1800 root      17   0  3356  284 1232 S  0.0  0.1   0:00.00 mingetty
 1801 root      17   0  2092  284 1232 S  0.0  0.1   0:00.00 mingetty
 1802 root      18   0  2392  284 1232 S  0.0  0.1   0:00.00 mingetty
 1803 root      18   0  2348  284 1232 S  0.0  0.1   0:00.00 mingetty

Uptime:
23:43:52 up 11 days, 9:41, 1 user, load average: 8.02, 8.02, 7.84


Nog geen effect?...

[JeRa]

Draai je een packaged kernel van Fedora of een eigen kernel? Dit lijkt me niet normaal, zeker niet als hij niet wil rebooten; ik zelf zou denken aan een kernelfoutje.

[TheBorg]

Ff sorteren op CPU time, dan kun je het beter zien.

[Startups]

JeRa schreef op dinsdag 14 december 2004 @ 23:44:
Draai je een packaged kernel van Fedora of een eigen kernel? Dit lijkt me niet normaal, zeker niet als hij niet wil rebooten; ik zelf zou denken aan een kernelfoutje.

Standaard fedora kernel.

[WPN]

je kan altijd nog de stroom eraf trekken, niet de netste manier van afsluiten, maar als je perce wilt reboot maar niet softwarematig lukt....

[JeRa]

Ook geprobeerd zoveel mogelijk services (httpd, ftpd) uit te zetten? Mocht het geen resultaat hebben dan weet je in ieder geval zeker dat het niet daaraan lag en kun je het probleem verder tracen. Heb je eigenlijk last van die hoge load? (is 't merkbaar?)

[ Voor 14% gewijzigd door JeRa op 14-12-2004 23:53 ]

[Nakebod]

In je 2e logje:
11685 apache 15 0 19384 11m 14m S 0.3 2.7 0:00.62 httpd
Lijkt me ook extreem hoog.

Maar eh, fedora? dat is toch van Redhat? Wat ik mij kan herinneren van rh was dat ookal was je root, eigenlijk nog niets kon, moet je per se inloggen met su - ipv gewoon su zoals dat overal wel gewoon werkt.
Misschien dat je daarom geen reboot kan doen?

[Verwijderd]

Wat voor melding krijg je als je dit doet:

code:

# /sbin/shutdown -r now

?

[Startups]

Verwijderd schreef op dinsdag 14 december 2004 @ 23:57:
Wat voor melding krijg je als je dit doet:

code:

# /sbin/shutdown -r now

?

dan krijg ik

code:

Broadcast message from root (pts/12) (Wed Dec 15 00:03:46 2004):

The system is going down for reboot NOW!

Vervolgens blijft hij gewoon werken... niets van een reboot te merken..

Nog wat processen dood gemaakt..

Maar nog steeds hoge load
Hij is op weg naar de 9
00:06:33 up 11 days, 10:04, 1 user, load average: 8.93, 8.42, 8.08


Top:

code:

top - 00:02:46 up 11 days, 10:00,  1 user,  load average: 8.00, 8.00, 7.91
Tasks:  65 total,   2 running,  63 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0% us,  0.3% sy,  0.0% ni, 99.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    452140k total,   259176k used,   192964k free,    29048k buffers
Swap:  1048816k total,      428k used,  1048388k free,   189632k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13684 root      16   0  2856  904 1620 R  0.3  0.2   0:00.06 top
    1 root      16   0  2640  456 1316 S  0.0  0.1   0:05.08 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.09 ksoftirqd/0
    3 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 events/0
    4 root       5 -10     0    0    0 S  0.0  0.0   0:00.00 kblockd/0
    6 root      13 -10     0    0    0 S  0.0  0.0   0:00.00 khelper
    5 root      15   0     0    0    0 S  0.0  0.0   0:00.00 khubd
    7 root      15   0     0    0    0 S  0.0  0.0   0:01.05 pdflush
    8 root      15   0     0    0    0 S  0.0  0.0   0:00.58 pdflush
   10 root      15 -10     0    0    0 S  0.0  0.0   0:00.00 aio/0
    9 root      15   0     0    0    0 S  0.0  0.0   0:01.29 kswapd0
  114 root      22   0     0    0    0 S  0.0  0.0   0:00.00 kseriod
  148 root      15   0     0    0    0 S  0.0  0.0   0:25.09 kjournald
 1456 root      16   0  2812  588 1296 S  0.0  0.1   0:01.63 syslogd
 1460 root      16   0  2176  456 1244 S  0.0  0.1   0:00.02 klogd
 1551 root      16   0  2896  760 1368 S  0.0  0.2   0:00.01 smartd
 1560 root      18   0  1836  464 1236 S  0.0  0.1   0:00.00 acpid
 1604 root      16   0  2360  896 1684 S  0.0  0.2   0:00.00 xinetd
 1613 root      16   0  2568  956 2236 S  0.0  0.2   0:00.06 da-popb4smtp
 1622 nobody    15   0  4292 1048 3856 S  0.0  0.2   0:00.64 directadmin
 1707 root      16   0  1676  560 1364 S  0.0  0.1   0:00.13 vm-pop3d
 1727 root      17   0  2328  652 1356 S  0.0  0.1   0:00.68 crond
 1766 daemon    16   0  2488  568 1348 S  0.0  0.1   0:00.00 atd
 1782 root      16   0  2712  348 1292 S  0.0  0.1   0:00.00 mdadm
 1799 root      17   0  3072  288 1232 S  0.0  0.1   0:00.00 mingetty
 1800 root      17   0  3356  288 1232 S  0.0  0.1   0:00.00 mingetty
 1801 root      17   0  2092  288 1232 S  0.0  0.1   0:00.00 mingetty
 1802 root      18   0  2392  288 1232 S  0.0  0.1   0:00.00 mingetty
 1803 root      18   0  2348  288 1232 S  0.0  0.1   0:00.00 mingetty
 1804 root      18   0  1692  288 1232 S  0.0  0.1   0:00.00 mingetty
29761 root      17   0  5012 1464 3424 S  0.0  0.3   0:01.97 sshd
30771 root      17   0  2332  656 1356 S  0.0  0.1   0:00.00 crond
30772 root      17   0  2820  784 1828 S  0.0  0.2   0:00.00 sh
30777 mail      16   0  7924 1728 6244 S  0.0  0.4   0:00.00 sendmail
30778 root      17   0  3076  456 1284 D  0.0  0.1   0:00.00 quotaon
31924 root      18   0  5320  708 3384 D  0.0  0.2   0:00.00 setquota
24774 root      18   0  2324  648 1356 S  0.0  0.1   0:00.00 crond
24775 root      18   0  4224  784 3864 S  0.0  0.2   0:00.00 dataskq
24776 root      18   0  2732  780 1828 S  0.0  0.2   0:00.00 sh
24777 root      18   0  2572  440 1276 D  0.0  0.1   0:00.00 repquota
32038 root      16   0  1676  560 1364 S  0.0  0.1   0:00.00 vm-pop3d
32039 root      15   0  1676  560 1364 S  0.0  0.1   0:00.00 vm-pop3d
32040 root      16   0  1676  560 1364 S  0.0  0.1   0:00.00 vm-pop3d

[mrFoce]

Peluso schreef op dinsdag 14 december 2004 @ 23:51:
je kan altijd nog de stroom eraf trekken, niet de netste manier van afsluiten, maar als je perce wilt reboot maar niet softwarematig lukt....

Hij vermeld niet waar de server staat, misschien is die wel dedicated ergens bij een bedrijf en dan gaat dat een beetje moeilijk

[Startups]

gideon82 schreef op woensdag 15 december 2004 @ 00:04:
[...]


Hij vermeld niet waar de server staat, misschien is die wel dedicated ergens bij een bedrijf en dan gaat dat een beetje moeilijk

Staat in Nederland, geen apc erbij helaas..

[TheBorg]

Je kan natuurlijk altijd even vragen of ze op het reboot knopske willen drukken.

[ Voor 5% gewijzigd door TheBorg op 15-12-2004 00:09 ]

[Verwijderd]

Hmmm, dit is erg vreemd, en doet me denken aan een probleem met APM, wat ik ooit had met mandrake 10 op m'n epia serv. APM vervangen door ACPI, en in de BIOS van het beestje aangezet, en hij wou weer.

Verder vind ik die load érg vreemd, bij mijn weten gaven die getallen aan wat de load is, in percentage. De enige manier waarop je boven de 1.00 uitkomt is als je meer CPU's hebt. 8.00 zal betekenen 8CPU's. Dat lijkt me erg onlogisch.

Het reboot commando, doet dat wel? Probeer anders "halt". Natuurlijk als SU-zijnde.

[Startups]

TheBorg schreef op woensdag 15 december 2004 @ 00:09:
Je kan natuurlijk altijd even vragen of ze op het reboot knopske willen drukken.

Ik wil weten wat er aan de hand is, mag niet nog is gebeuren..

Uptime:
00:16:23 up 11 days, 10:14, 1 user, load average: 9.99, 9.63, 8.83

Dit is niet goed..

[mrFoce]

keel schreef op woensdag 15 december 2004 @ 00:08:
[...]

Staat in Nederland, geen apc erbij helaas..

dan zou ik even het bedrijf bellen en vragen om een 'harde reset' lijkt me de enige en snelste oplossing

[Startups]

gideon82 schreef op woensdag 15 december 2004 @ 00:15:
[...]


dan zou ik even het bedrijf bellen en vragen om een 'harde reset' lijkt me de enige en snelste oplossing

dat kost me 45 euro, en dan weet ik nog steeds niet of het vaker gaat gebeuren, voor hetzelfde geld loopt die load diezelfde minuut weer op..

[Erkens]

Verwijderd schreef op woensdag 15 december 2004 @ 00:10:
Verder vind ik die load érg vreemd, bij mijn weten gaven die getallen aan wat de load is, in percentage. De enige manier waarop je boven de 1.00 uitkomt is als je meer CPU's hebt. 8.00 zal betekenen 8CPU's. Dat lijkt me erg onlogisch.

een load van 8 betekend dat er veel processen staan te wachten op CPU time

[T-h-i-j-s]

Doet me denken aan het hangen op 'open files' die niet gesloten kunnen worden.
dwz: ik ken het van bakken waar er bijvoorbeeld een probleem is met een van de harddisks, harddisk controller, een hangende NFS-mount, oid. Het proces kan dan niet netjes afsluiten, omdat er nog files openstaan die niet gesloten kunnen worden. Daardoor blijven processen actief, vandaar dat de load omhoog gaat (niet dat de processen daadwerkelijk wat doen (cpu-usage), maar het telt wel mee voor de load). Shutdown werkt ook niet, omdat ook die niet netjes kan afsluiten.

Enige oplossing: 230V-reset. Er zal dus iemand op knoppen moeten gaan duwen of stekkers trekken.

Kijk eens in je kernel-logging. Zie je daar errors voorbij komen?
Kijk eens naar de processen die blijven hangen en die je ook niet gekilled krijgt. Welke files hebben die open (lsof -p)?

[PowerSp00n]

Verwijderd schreef op woensdag 15 december 2004 @ 00:10:
Verder vind ik die load érg vreemd, bij mijn weten gaven die getallen aan wat de load is, in percentage. De enige manier waarop je boven de 1.00 uitkomt is als je meer CPU's hebt. 8.00 zal betekenen 8CPU's. Dat lijkt me erg onlogisch.

Nee de load heeft te maken met het gemiddelde aantal processen naar ik meen 5, 10 en 15 minuten ofzo, het aantal minuten kan er iets naast zitten.

[edit] ik was ook een beetje laat

[ Voor 58% gewijzigd door PowerSp00n op 15-12-2004 00:19 ]

[Verwijderd]

Zeer vage bedoening. Je idle percentage is telkens meer dan 99%, dus je hebt volgens mij helemaal geen load. (Top verbruikt nog het meeste, zo te zien ). Ik had toevallig net op mijn eigen computer een vastgelopen procesje die zowat alle cpu-tijd opat, maar de avarage load kwam niet boven de 1.2 uit.

[Startups]

lsof (werd om gevraagd, zegt mij persoonlijk niets, hier stopt mijn kennis..)

code:

[root@main root]# lsof -p
lsof: no process ID specified
lsof 4.68
 latest revision: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
 latest FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
 latest man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man
 usage: [-?abhlnNoOPRstUvV] [+|-c c] [+|-d s] [+D D] [+|-f]
 [-F [f]] [-g [s]] [-i [i]] [+|-L [l]] [+|-M] [-o [o]] [-p s]
 [+|-r [t]] [-S [t]] [-T [t]] [-u s] [+|-w] [--] [names]
Use the ``-h'' option to get more help information.
[root@main root]# lsof -p 1
COMMAND PID USER   FD   TYPE DEVICE    SIZE    NODE NAME
init      1 root  cwd    DIR    3,1    4096       2 /
init      1 root  rtd    DIR    3,1    4096       2 /
init      1 root  txt    REG    3,1   36848 8798316 /sbin/init
init      1 root  mem    REG    3,1  106892 2198333 /lib/ld-2.3.3.so
init      1 root  mem    REG    3,1 1455084 2198334 /lib/tls/libc-2.3.3.so
init      1 root  mem    REG    3,1   60776 2198336 /lib/libselinux.so.1
init      1 root   10u  FIFO    3,1         2797216 /dev/initctl
[root@main root]# lsof -p 2
COMMAND   PID USER   FD   TYPE DEVICE SIZE NODE NAME
ksoftirqd   2 root  cwd    DIR    3,1 4096    2 /
ksoftirqd   2 root  rtd    DIR    3,1 4096    2 /

[T-h-i-j-s]

load != cpu-usage

cpu usage: het percentage cpu-cycles dat verbruikt wordt
load: het aantal processen dat (gelijktijdig) processing-tijd vraagt

In dit geval zijn er dus hangende processen die 'actief' zijn, maar effectief geen cpu gebruiken (ze hangen namelijk).

[T-h-i-j-s]

keel > je zult er eerst achter moeten komen welke de processen zijn die 'hangen'. Bijvoorbeeld door stelselmatig de verschillende processen te killen (begin met de hoogste PIDs, Process ID).
De processen die je niet gekilled krijgt, zijn waarschijnlijk de hangende processen.

met "ps ax" krijg je een overzicht ('ps faux' kan soms ook handig zijn). Daar zie je ook het PID van elk proces.
Als je er dan achter bent welke PIDs blijven hangen kun je met 'lsof -p <PID>' nagaan welke files die processen open hebben.

Maar ik betwijfel eerlijk gezegd of ik je hiermee help, want ik heb het idee dat het allemaal erg nieuw en onbekend voor je is. Ik raad je aan om iemand met wat meer ervaring te vragen om met je mee te kijken. Ik vrees dat de uitvoer van lsof meer vragen oproept dan beantwoordt.

Een ding ben ik vrij zeker van: die bak heeft een harde reset nodig.

[ Voor 7% gewijzigd door T-h-i-j-s op 15-12-2004 00:31 ]

[Oceria]

TheBorg schreef op dinsdag 14 december 2004 @ 23:45:
Ff sorteren op CPU time, dan kun je het beter zien.

Inderdaad, hier zie je verder niks. In top gewoon [shift]+[p] intoetsen. Het proces dat de meeste CPU tijd gebruikt (wordt als eerste weergegeven) kun je daarna killen met een signaal 9.
Als je CPU load dan niet terugloopt weet ik het ook niet meer
btw, voor een shutdown -r now moet je wel als root ingelogd zijn! Dus eerst ff "su" en wachtwoord van de root intypen, dan shutdown -r now.

Je load is echter heel hoog zonder dat je cpu veel lijkt te doen: id (idle) staat op 99%. Is je computer wel responsief, of doet hij inderdaad niks meer (behalve niet rebooten )
Het lijkt inderdaad wel of er ergens in je APM/ACPI instellingen iets raars zit, waardoor de loadberekeningen verkeerd uitkomen.
Succes iig!

[Kippenijzer]

geeft dmesg niet heel veel harddisk errors ofzo? en wat geeft vmstat -n 5, als je die, zeg, een minuut laat draaien? Kan het zijn dat gewoon je IO naar de K* is, dan zie je dat met vmstat wel denk ik,.

[T-h-i-j-s]

Zo te zien hangen je quota-processen (repquota, quotaon, setquota), te zien aan de D-state (uninterruptible sleep) in de STAT kolom van top.
Dat zou dus heel goed op een probleem met je harddisk of controller kunnen duiden...

[Startups]

Iemand zei na onderzoekje:
Je hebt enkele processes die hangen op quota-probleem in de kernel.

Aangeraden wordt zg. RebootA te gebruiken:

code:

#include <stdio.h>
#include <unistd.h>
#include <linux/reboot.h>

void main () {
    reboot(LINUX_REBOOT_CMD_RESTART);
}

Iemand een betere suggestie of commentaar?

[Tatsu]

Heb je scripts onder httpd draaien?

[TheBorg]

"reboot -f" kan ook nog alstie niet wil luisteren.

[Startups]

RebootA heeft gewerkt..

code:

 01:08:29 up 10 min,  1 user,  load average: 0.00, 0.03, 0.03

Bedankt voor de steun!
En Zylon Internet Services voor de support!

Topic mag dicht.

[ Voor 6% gewijzigd door Startups op 15-12-2004 01:09 ]

[Tatsu]

keel schreef op woensdag 15 december 2004 @ 01:08:
RebootA heeft gewerkt..

code:

 01:08:29 up 10 min,  1 user,  load average: 0.00, 0.03, 0.03

Bedankt voor de steun!
En Zylon Internet Services voor de support!

Topic mag dicht.

Natuurlijk wel het een en ander in de gaten blijven houden om een permanent probleem uit te sluiten.
Good luck.

[Startups]

Tatsu schreef op woensdag 15 december 2004 @ 01:17:
[...]

Natuurlijk wel het een en ander in de gaten blijven houden om een permanent probleem uit te sluiten.
Good luck.

doe ik!

01:19:10 up 20 min, 1 user, load average: 0.02, 0.02, 0.00

bedankt!