Peculiar Process Name In /proc

Home » CentOS » Peculiar Process Name In /proc
CentOS 4 Comments

Hello,

I was looking at a process through the ‘/proc’ file system, and came across a process name which seemed to contain a hex value:

lrwxrwxrwx. 1 xymon xymon 0 Aug 2 14:07 /proc/58032/exe ->
/usr/sbin/xymond;5d44410e (deleted)

I am aware of what the ‘deleted’ part means, but have no idea what the
‘;5d44410e’ part means. Is this some sort of thread reference?
The file ‘/usr/sbin/xymond’ does exist and is running as a daemon.

Anyone know what the ‘;5d44410e’ is referring to? I have tried Googling about this, but found no mention of it.

Thanks,

John.

4 thoughts on - Peculiar Process Name In /proc

  • I am not absolutely sure, but is it saying that /usr/sbin/xymond was deleted, but was located at that inode reference on the disk?

    I know you say it exists, but perhaps it was deleted since running and then re-created? or perhaps it is an self-modifying executable?

  • The hex number is quite large, and too big I suspect for the number of inodes allowed on the partition.

    I was going to say no to both of these, however the RPM package (‘xymon’) was itself updated at around the time mentioned on Aug 02. The hex number is equivalent to 1564754190 in decimal which, as an epoch time, is ‘2019-08-02 14:56:30’. So it might be possible that ‘/usr/sbin/xymond’ was replaced and the hex number just indicates the time that occurred.

    The downside is that the package update was a bit earlier than 14:56 though, so the numbers don’t seem to quite match up. Secondly, the whole xymon process was restarted, but the server itself not rebooted, so I would expect all the processes to be using the new executables rather than an older/deleted one. (I
    am a little loath to restart the service at the moment as I may well lose the info currently in ‘/proc/…/exe’.)

    John.

  • It might be explained that the file doesn’t get deleted until its file handles are released?
    Did you upgrade xymon, or perhaps install it from a different maintainers RPM from the original one, or perhaps the original one wasn’t an RPM install at all?

    In these cases, the old running process in /proc/pid/exe is probably the original one, which the new install tried to restart / but because of a discrepancy in what is in /var/run it didn’t quite work out as planned.

    I think to truly understand this we might need more background information and a journal of what tasks were carried out.

  • IIRC that’s the inode of the file, that still exists until the last reference goes away. Restarting the service, perhaps as part of a reboot, will end the reference and free the inode causing the new file to be used.

    /mark