Re: MpxTestDaemon

Thanks Mladen.

That was one of the first things I tried.

There are no files open for that process.

There is also no content in cmdline.

Jared

On Wed, Oct 21, 2020 at 10:38 Mladen Gogala <gogala.mladen_at_gmail.com> wrote:

> Hi Jared,
>
> If that is Linux, go to /proc/<pid>/fd and see what files does the process
> have open. Also, find the xeceutable and do ldd on it. That will show you
> the libraries. That looks something like this:
>
> root_at_umajor:/home/mgogala# *ldd /usr/bin/python3*
> linux-vdso.so.1 (0x00007fff9458a000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c53013000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f8c52ff0000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8c52fea000)
> libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f8c52fe5000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8c52e96000)
> libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1
> (0x00007f8c52e68000)
> libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8c52e4a000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f8c53230000)
>
> If the process uses EMC libraries, you know who to ask. As for the /proc
> trick, it goes like this:
>
> root_at_umajor:/proc/39972# cd /proc/39972/fd
> root_at_umajor:/proc/39972/fd# ls -l
> total 0
> lrwx------ 1 root root 64 Oct 21 12:50 0 -> /dev/pts/0
> lrwx------ 1 root root 64 Oct 21 12:50 1 -> /dev/pts/0
> lrwx------ 1 root root 64 Oct 21 12:50 2 -> /dev/pts/0
> lrwx------ 1 root root 64 Oct 21 13:22 255 -> /dev/pts/0
> root_at_umajor:/proc/39972/fd# ps -fp 39972
> UID PID PPID C STIME TTY TIME CMD
> root 39972 39868 0 12:50 pts/0 00:00:00 bash
> root_at_umajor:/proc/39972/fd#
>
> This is bash, it holds the terminal. You can also check
> /proc/<pid>/map_files. It gives you more details than ldd. If you are
> lucky, the executable will have some symbols, but mostly they do not.
> Symbols are usually stripped off:
>
> root_at_umajor:/proc/39972/map_files# nm /bin/bash
> nm: /bin/bash: no symbols
>
> Instead of nm, you can use objdump --syms -T /bin/bash The result looks
> like this:
>
> bin/bash: file format elf64-x86-64
>
> SYMBOL TABLE:
> no symbols
>
>
> DYNAMIC SYMBOL TABLE:
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 endgrent
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3
> __ctype_toupper_loc
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 iswlower
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 sigprocmask
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.4
> __snprintf_chk
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 free
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 getservent
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 wcscmp
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 putchar
> 0000000000000000 DF *UND* 0000000000000000
> NCURSES6_TINFO_5.0.19991023 tputs
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 strcasecmp
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 localtime
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 mblen
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.4
> __vfprintf_chk
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 abort
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5
> __errno_location
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 strncpy
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 strncmp
> 0000000000000000 w D *UND* 0000000000000000
> _ITM_deregisterTMCloneTable
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 wcscoll
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 strcpy
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 getgrent
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 iconv
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 puts
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 ferror
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 qsort
> 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 isatty
>
> The names should allow you to guess the purpose. Should all else fail,
> there is always the good, old "strings" command. Of course, you can use
> strace and ltrace to see what is the process doing. That might give you
> some idea about what it is.
>
> Regards
>
>
>
>
>
>
>
> On 10/20/20 6:00 PM, Jared Still wrote:
>
> Dear list:
>
> I am investigating a process 'MpxTestDaemon' on a Linux server (RedHat 6.9
> as I recall).
>
> This server is running Oracle 12.1, and has 1.5T of RAM.
>
> It is a standalone server, not RAC.
>
> There are some anomalous things occurring with this process.
>
> For instance, at times pidstat reports impossible numbers of minflt/s
> (mem faults not requiring disk access) being performed: approx 1.85 * 10e18
>
> Right now though all I am asking is this:
>
> Does anyone know what this process is?
>
> Neither Oracle nor the Google have anything helpful.
>
> In Oracle's case, no references at all.
>
> In the meantime, I shall see if I can find out what it is doing.
>
> Thanks.
>
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
> Principal Consultant at Pythian
> Oracle ACE Alumni
> Pythian Blog http://www.pythian.com/blog/author/still/
> Github: https://github.com/jkstill
>
>
> --
> Mladen Gogala
> Database Consultant
> Tel: (347) 321-1217
>
> --
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist Principal Consultant at Pythian
Oracle ACE Alumni
Pythian Blog http://www.pythian.com/blog/author/still/ Github: https://github.com/jkstill

--
http://www.freelists.org/webpage/oracle-l