<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: kill process in Operating System - Linux</title>
    <link>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613396#M40371</link>
    <description>hi, &lt;BR /&gt;&lt;BR /&gt;your problem is that process  _ora1 listens on port (ora2=)7158. once it receives a connection it hands over control of the connection to or spawns thread/process _ora2 to take care of further communication. once the process _ora2 makes connection on the same port 7158 no other clients are allowed to connect to the same port.&lt;BR /&gt;the most probably your _ora1 and _ora2 processes tries to connect to ORACLE very non-standard way and therefore you have problems.&lt;BR /&gt;&lt;BR /&gt;as  processes "_ora1" and "_ora2"? seem not to be anything standard from ORACLE but rather something very specific to your environment the best would really be to discuss it with application owner/developer what's really going on.&lt;BR /&gt;&lt;BR /&gt;if you can not do that, you have to provide much more info about your env and ORACLE related setup.&lt;BR /&gt;&lt;BR /&gt;emha.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Thu, 08 Apr 2010 20:38:49 GMT</pubDate>
    <dc:creator>emha_1</dc:creator>
    <dc:date>2010-04-08T20:38:49Z</dc:date>
    <item>
      <title>kill process</title>
      <link>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613394#M40369</link>
      <description>&lt;BR /&gt;The below is the output of lsof -i tcp:7158&lt;BR /&gt;&lt;BR /&gt;COMMAND    PID USER   FD   TYPE   DEVICE SIZE NODE NAME&lt;BR /&gt;_ora1  5168 root   13u  IPv4 584587222       TCP *:ora2 (LISTEN)&lt;BR /&gt;_ora2  5168 root   14u  IPv4 848578242       TCP ORA:ora2-&amp;gt;192.168.100.37:&lt;BR /&gt;5878 (ESTABLISHED)&lt;BR /&gt;&lt;BR /&gt;"&lt;BR /&gt;"&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;I found that the process 5168 is locking the database , now the user can't access the database via the service port 7158 , I have to kill it to release the service port , but if I kill it , then I have to restart the database also , otherwise , I can't re-start the service port , can advise how can I only kill the device ID 848578242 , instead of kill the pid 5168 ? thx</description>
      <pubDate>Wed, 07 Apr 2010 09:20:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613394#M40369</guid>
      <dc:creator>ivy1234</dc:creator>
      <dc:date>2010-04-07T09:20:34Z</dc:date>
    </item>
    <item>
      <title>Re: kill process</title>
      <link>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613395#M40370</link>
      <description>This appears to be all about the Oracle database: some request has come in that "locks the database", then doesn't release the lock in a reasonable amount of time.  I put "locks the database" in quotes, since polite applications only lock individual table rows, rude ones only lock entire tables, and only broken ones lock the entire database.  If they're available, I would talk to the application folks about what the database client is trying to accomplish, and why it isn't.&lt;BR /&gt;&lt;BR /&gt;If the application folks aren't available to collaborate, in a pinch I'd try forging a TCP RST packet from the client, simulating the client's response had it been rebooted in the middle of the session, telling the server OS to terminate the connection (this probably requires discovering the current TCP sequence number, or the RST packet will be rejected as inauthentic; that means either diving into the kernel data structures for the connection or using something like the libpcap library in a sniffing program to record the sequence numbers of interest); if you're lucky, the database server process will notice the terminated connection and abort the request it's servicing.  See the discussion at &lt;A href="http://forum.soft32.com/linux/killing-socket-connection-cmdline-ftopict473059.html" target="_blank"&gt;http://forum.soft32.com/linux/killing-socket-connection-cmdline-ftopict473059.html&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;An expert in Oracle will probably have a more elegant solution.  Collaborating with the application developers is best.</description>
      <pubDate>Wed, 07 Apr 2010 13:55:26 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613395#M40370</guid>
      <dc:creator>Stephen P. Schaefer</dc:creator>
      <dc:date>2010-04-07T13:55:26Z</dc:date>
    </item>
    <item>
      <title>Re: kill process</title>
      <link>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613396#M40371</link>
      <description>hi, &lt;BR /&gt;&lt;BR /&gt;your problem is that process  _ora1 listens on port (ora2=)7158. once it receives a connection it hands over control of the connection to or spawns thread/process _ora2 to take care of further communication. once the process _ora2 makes connection on the same port 7158 no other clients are allowed to connect to the same port.&lt;BR /&gt;the most probably your _ora1 and _ora2 processes tries to connect to ORACLE very non-standard way and therefore you have problems.&lt;BR /&gt;&lt;BR /&gt;as  processes "_ora1" and "_ora2"? seem not to be anything standard from ORACLE but rather something very specific to your environment the best would really be to discuss it with application owner/developer what's really going on.&lt;BR /&gt;&lt;BR /&gt;if you can not do that, you have to provide much more info about your env and ORACLE related setup.&lt;BR /&gt;&lt;BR /&gt;emha.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 08 Apr 2010 20:38:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-linux/kill-process/m-p/4613396#M40371</guid>
      <dc:creator>emha_1</dc:creator>
      <dc:date>2010-04-08T20:38:49Z</dc:date>
    </item>
  </channel>
</rss>

