https://bugzilla.novell.com/show_bug.cgi?id=445870 Summary: there is no way to confirm whether a node is kdumping or not from other node Product: openSUSE.org Version: unspecified Platform: Other OS/Version: UNIX Other Status: NEW Severity: Enhancement Priority: P5 - None Component: bugzilla AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: taniguchis@intellilink.co.jp QAContact: novbugzilla-bugs@forge.provo.novell.com Found By: --- At the present time, there is no way to confirm whether a node is kdumping or not from other node. If the node is running, _not_ kdumping, and its network interface is running fine, then you can connect to it via ssh to check the size of /proc/vmcore. But if the node is kdumping, the way above is not practicable. Because 2nd kernel doesn't have sshd and it doesn't bring a network I/F up (except a case of dumping to remote location). It causes some problems with Clustering. For example, when kernel panic occurs, kdump is executed in 2nd kernel on the node. But it is killed by Node-Fencing function (for example STONITH in Heartbeat) before kdump finishes, and consequently nothing is dumped. This is a serious problem for failure analysis. So, I consider that mkdumprd needs the following functions. 1) Bring the specified network interface up irrespective of location of dumping. 2) Copy sshd and its setting files to the 2nd kernel's initrd and start the daemon. 3) Add non-root user to the 2nd kernel. The function 3) should require some explanations. For example, Heartbeat has a STONITH plugin, "kdumpcheck", to check whether the node is kdumping or not. This plugin is a shell script. It is for avoiding fencing the node which is kdumping. It is executed by STONITH daemon automatically, so it requires that sshd allows passwordless login. And it is very dangerous to allow passwordless login to root user from a security point of view. So, the 2nd kernel needs non-root user. Maybe other Clustering solution's Node-Fencing function has the same issue. Now I attached a patch which has the following roles as an example. i) Start udevd with specified .rules files. ii) Bring the specified network interface up. iii) Start sshd. iv) Add the specified user to the 2nd kernel. v) Execute sync command after dumping. These expandings are only for the case that filesystem partition is specified as the location where the vmcore should be dumped. This patch is tested with mkdumprd version 5.0.39. If you're interested in, please give me your comments. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.