search for: vmdaemon

Displaying 8 results from an estimated 8 matches for "vmdaemon".

Did you mean: mdaemon
2003 Apr 11
2
no idle CPU ... system hogging it all ...
...0.00 0 0.00 0.00 0 0.00 7 0 93 0 0 8 33 15.13 8 0.11 0.00 0 0.00 0.00 0 0.00 11 0 89 0 0 3 20 15.65 33 0.51 0.00 0 0.00 0.00 0 0.00 4 0 96 0 0 doing a ps, the 'server processes' don't look to be consuming much CPU, other then the vmdaemon/syncer (that is 18 and 9 hrs respectively, right?) USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 0.0 0 0 ?? DLs Thu07AM 0:45.80 (swapper) root 1 0.0 0.0 552 196 ?? SLs Thu07AM 0:03.37 /sbin/init -- root 2 0....
2003 Apr 20
0
4400+ cron processes causes server crash ...
...2 (pine) 4 (pipe) 31 (pop3d) 1 (portmap) 280 (postgres) 1 (ps) 4 (python2.1) 34 (qmgr) 1 (rpc.statd) 2 (rsync) 1 (rwhod) 1 (scp) 4 (screen) 14 (sh) 3 (ssh) 61 (sshd) 1 (swapper) 1 (syncer) 40 (syslogd) 18 (tcsh) 11 (timsieved) 1 (upclient) 1 (vmdaemon) 1 (vnlru) 1 COMMAND Is there any way of finding out what jails "owned" those cron jobs *after* the crash? I know I can find out on a running systems using proc/*/status, but what about after the server has crashed? :( On a 'normally running server', I see: neptune#...
2003 Jul 29
6
kernel deadlock
...ient 6 dc35c5e0 defd1000 0 0 0 000204 3 vlrup dc35c5e0 vnlru 5 dc35c780 defce000 0 0 0 000204 3 syncer c037c0c8 syncer 4 dc35c920 defcb000 0 0 0 000204 3 psleep c036487c bufdaemon 3 dc35cac0 defc8000 0 0 0 000204 3 psleep c0372fc0 vmdaemon 2 dc35cc60 defc5000 0 0 0 000204 3 psleep c0351e58 pagedaemon 1 dc35ce00 dc361000 0 0 1 004284 3 wait dc35ce00 init 0 c037b4a0 c040d000 0 0 0 000204 3 sched c037b4a0 swapper The hung tasks look like this: db> t 446 mi_switch(c34ab600,100004...
2002 Mar 09
1
smbd running multiple times
...taller@apache$ installer@apache$ /usr/local/sbin/smbd -V Version 2.2.3a installer@apache$ installer@apache$ ps -ax PID TT STAT TIME COMMAND 0 ?? DLs 0:00.00 (swapper) 1 ?? ILs 0:00.01 /sbin/init -- 2 ?? DL 0:00.00 (pagedaemon) 3 ?? DL 0:00.00 (vmdaemon) 4 ?? DL 0:00.00 (bufdaemon) 5 ?? DL 0:00.00 (vnlru) 6 ?? DL 0:00.01 (syncer) 69 ?? Ss 0:00.05 /usr/sbin/syslogd -a 192.168.7.1/24 73 ?? Ss 0:00.02 ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid 80 ?? Ss 0:00.00 /usr/sbin/cron 82 ?? Is...
2003 Apr 10
0
panic: vinvalbuf: flush failed
..._mfs 6 e34015e0 e7bb4000 0 0 0 000204 2 syncer 5 e3401780 e7bb1000 0 0 0 000604 2 vnlru 4 e3401920 e7bae000 0 0 0 000604 2 bufdaemon 3 e3401ac0 e7bab000 0 0 0 000204 3 psleep c042af20 vmdaemon 2 e3401c60 e7ba8000 0 0 0 000604 2 pagedaemon 1 e3401e00 e3406000 0 0 1 004284 3 wait e3401e00 init 0 c0434be0 c04de000 0 0 0 000204 3 sched c0434be0 swapper db> panic panic: from debugger Uptime: 2d23h10m42s dumping to dev #...
2006 Mar 17
1
Fatal trap 12: page fault while in kernel mode / current process=12 (swi1: net)
...0 0000204 [SLPQ vlruwt 0xffffff007b65c9c0][SLP] vnlru 29 ffffff007b5dd000 0 0 0 0000204 [SLPQ psleep 0xffffffff8056a4b8][SLP] bufdaemon 28 ffffff007b5dd340 0 0 0 000020c [RUNQ] pagezero 27 ffffff007b5dd680 0 0 0 0000204 [SLPQ psleep 0xffffffff8057116c][SLP] vmdaemon 26 ffffff007b90c680 0 0 0 0000204 [SLPQ psleep 0xffffffff8057111c][SLP] pagedaemon 25 ffffff007b90c9c0 0 0 0 0000204 [IWAIT] swi0: sio 24 ffffff007b95e000 0 0 0 0000204 [IWAIT] irq10: bge0 23 ffffff007b95e340 0 0 0 0000204 [IWAIT] irq5: nve0...
2008 Oct 14
1
FreeBSD 7-STABLE, isp(4), QLE2462: panic & deadlocks
...0 0 0 SL syncer 0xc0c5666c [syncer] 54 0 0 0 SL vlruwt 0xc6fec000 [vnlru] 53 0 0 0 RL CPU 5 [bufdaemon] 52 0 0 0 SL pgzero 0xc0cb5220 [pagezero] 51 0 0 0 SL psleep 0xc0cb4e38 [vmdaemon] 50 0 0 0 SL psleep 0xc0cb4e00 [pagedaemon] 49 0 0 0 SL waiting_ 0xc0caa434 [sctp_iterator] 48 0 0 0 WL [irq1: atkbd0] 47 0 0 0 WL [swi0: sio] 46 0 0 0 WL...
2004 Oct 29
2
Logging and libwrap
Hi, A few things regarding logging and libwrap.. a) PAM_RHOST patch Back in July, dean gaudet helpfully posted a patch to dovecot PAM_RHOST the remote IP. Is this going to be included in the main dovecot tree? It seems like a worthwhile addition. The more informative and concise the logging the better. See http://www.dovecot.org/list/dovecot/2004-July/004011.html for the original message.