CODEWITHSUNDEEP
unixinodelsof
user3602441
user3602441

Reputation: 17

lsof showing unlinked file for more than one process

can anyone explain how unlinked file can be held by more than one process? currently I see four processes for the same inode 1543

# /usr/local/bin/lsof +aL1 /dev/vg00/lvol4

Xvnc      20622 p32adm    2u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)
vncconfig 20649 p32adm    1u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)
vncconfig 20649 p32adm    2u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)
xterm     20650 p32adm    1u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)
xterm     20650 p32adm    2u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)
twm       20651 p32adm    1u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)
twm       20651 p32adm    2u   REG 64,0x40004 4587683840     0 1543 /home (/dev/vg00/lvol4)

Upvotes: 0

Views: 353

Answers (2)

Marcus Müller
Marcus Müller

Reputation: 36442

can anyone explain how unlinked file can be held by more than one process?

Yes, someone can.

First of all, the fact that it's unlinked now doesn't necessarily mean it was unlinked when the processes got their file handles.

But looking at your list, I'd presume these are things like shared memory segments, which don't need to have a filesystem node somewhere.

EDIT: OP asked for explanation of Shared Memory segments in comments, so here it is:

Modern CPUs and OSes isolate the address spaces of processes from each other, so process A can't access the memory of process B. If now A and B need to exchange information, one way of doing so is asking the operating system to map a few addresses into the respective memory spaces which are /the same/ memory for both processes. These segments need handles, and these handles are what I was referring to. For further information, man shm_overview.

Upvotes: 0

jlliagre
jlliagre

Reputation: 30833

While there is no particular reason to expect different processes not to share an unlinked file as already answered by Marcus Müller, in your case these files are the processes stdout and stderr.

I guess these processes all inherited these file descriptors from an original command launched this way:

Xvnc ... > someLogFile 2>&1

and later, someLogFile was removed to (unsuccessfully) recover space.

Upvotes: 1

Related Questions