Solaris平台上的Oracle数据库，Alert日志偶尔会出现”Network Interface No Longer Operational”的相关记录：
ospid 11223: network interface with IP address 192.4.1.22 no longer operational requested interface 192.4.1.22 ioctl get mtu. Check output from ifconfig command
该错误一般是由Solaris操作系统Bug 6546482引起的，该错误一般可以忽略。
Network Interface No Longer Operational’ Message in the Alert.log File while NIC Is Running Fine
Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 10.2.0.5
Oracle Net Services – Version: 10.2.0.1 to 10.2.0.5
Sun Solaris SPARC (64-bit)
Symptoms
— Problem Statement:
The following messages are seen in the alert.log file :
Tue Dec 16 10:01:55 2008
ospid 6526: network interface with IP address 192.168.83.64 no longer operational
requested interface 192.168.83.64 ioctl get mtu. Check output from ifconfig command
These messages repeat periodically at random intervals.
At the time when these messages are printed, it is verified that there is no problem with the network interface in the message.
Cause
This is a known Sun Solaris bug : Bug ID 6546482 – Synopsis ioctl call fails with EINTR
Reference :
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6546482
http://sunsolve.sun.com/search/document.do?assetkey=1-1-6546482-1
RDS ioctl call is failing with EINTR.
Solution
— To implement the solution, please execute the following steps::
Contact the OS Vendor for providing the fix for Sun Bug ID 6546482
Oracle Cluster process logs “network interface with IP address a.b.c.d no longer operational” message
Symptoms
Oracle(R) RAC Cluster process issues messages similar to the following :
Mon Jun 8 10:04:22 2009 ospid 9966: network interface with IP address 172.23.45.67 no longer operational
Mon Jun 8 10:05:22 2009 ospid 9966: network interface with IP address 172.23.45.67 is now running
172.23.45.67 being the address of an interconnect interface.
Frequency is about twice a month.
No further impact observed, all services run normally.
Resolution
Root cause is the signal handling within the ora_lmd process.
This is being addressed in Oracle Bug ID: 8660487 at this time.
Relief/Workaround
There is no further impact to the application (other than above messages being printed).
Additional Information
The root cause could be found after writing a little test program issuing
the respective ioctl() system calls and by using a debug binary ora_lmd
collecting the corresponding errno when the ioctl() system call returned
an error.
Product
Oracle Real Application Clusters
Oracle in Infiniband. Here, as a fix for Oracle(R) RDS, signals were masked
while being in the rds_dl_info() function. On a multi-tasking system this
lowers probability of this situation but cannot completely exclude it.
Furthermore it’s special for the Infiniband RDS interface for Oracle.
As a more general fix, Oracle will look at the signal handling in the
ora_lmd process.
Progress and status of this is documented in Oracle Bug ID: 8660487.
References :
Sun SR 71139694
Sun CR SUNBUG: 6546482 ioctl call fails with EINTR
Oracle SR 7372738.992
Oracle Bug ID: 8660487
Bug 6546482: ioctl call fails with EINTR
Fix Request Attributes:
Description:
Oracle processes output the following messages when running with RDS:
Fri Mar 30 23:01:16 2007
ospid 184674: network interface with IP address 172.16.2.1 no longer operational
Fri Mar 30 23:02:16 2007
ospid 184674: network interface with IP address 172.16.2.1 is now running
These messages repeat periodically at random intervals. At the time when these messages are printed, it is verified that there is no problem with the network interface in the message.
It has been identified that the RDS ioctl call was failing with EINTR.
Suggested Fix:
$ sccs diffs rds_ioctl.c
——- rds_ioctl.c ——-
93a94
> k_sigset_t smask;
105a107
> sigintr(&smask, 0);
106a109
> sigunintr(&smask);
109a113
> sigunintr(&smask);
111a116
> sigunintr(&smask);
134c139,144
< static boolean_t
—
> /*
> * Return 0 if the interface is IB.
> * Return error (>0) if any error is encountered during process.
> * Return -1 if the interface is not IB and no error.
> */
> static int
159c169
< return (B_FALSE);
—
> return (-1);
166c176
< return (B_TRUE);
—
> return (0);
173c183
< return (B_FALSE);
—
> return (ret);
177d186
<
178a188,190
> if (ret != 0) {
> return (ret);
> }
180,182c192,194
< if (ret != 0 || (info.dl_mac_type != DL_IB &&
< !rds_transport_ops->rds_transport_if_lookup_by_name(name))) {
< return (B_FALSE);
—
> if (info.dl_mac_type != DL_IB &&
> !rds_transport_ops->rds_transport_if_lookup_by_name(name)) {
> return (-1);
185c197
< return (B_TRUE);
—
> return (0);
229c241,242
< if (rds_is_ib_interface(ifr->ifr_name)) {
—
> err = rds_is_ib_interface(ifr->ifr_name);
> if (err == 0) {
230a244,248
> } else if (err > 0) {
> num_ifs = 0;
> break;
> } else {
> err = 0;
280c298,299
< if (rds_is_ib_interface(ifr->ifr_name)) {
—
> err = rds_is_ib_interface(ifr->ifr_name);
> if (err == 0) {
284a304,307
> } else if (err > 0) {
> break;
> } else {
> err = 0;
434c457
< rds_is_ib_interface(ifr->ifr_name)) {
—
> (rds_is_ib_interface(ifr->ifr_name) == 0)) {
$
Fix Request Attributes:
Suggested Fix:
See Main CR