Lots of sh-np-<INSERT RANDOM NUMBER> files in /tmp

Da Fox · Guru Joined: 06 Jul 2005 Posts: 341

Since a while, perhaps a week or two weeks ago I have been getting a lot of strange files appear in /tmp. At first I thought it was just some random program malfunctioning and would be solved soon enough by a emerge --update world. However it has been some time now and I am still getting these. I don't know where they come from, there is nothing in the logs and "lsof | grep -i sh-np" hasn't yet shown any results. Has anyone else seen similar files, or know where these files are coming from? Or better yet, how to get rid of them?
Here is (some) output from ls:

didymos · Posted: Sun Apr 30, 2006 10:44 pm Post subject:

Well, as it said, they are named pipes. Some process created them and didn't clean up after itself. You won't get anything with cat because nothing is being piped anymore.
_________________
Thomas S. Howard

Da Fox · Guru Joined: 06 Jul 2005 Posts: 341

I understand that, I just wanted to show that the creating process really didn't do anything with them anymore, aka didn't exist anymore.
_________________
"Man fears the darkness, and so he scrapes away at the edges of it with fire."
- Rei Ayanami

JGBE, a Java based GameBoy Emulator

hjnenc · Posted: Mon May 01, 2006 7:42 am Post subject:

I noticed them on my system as well. It started about one week ago after I upgraded to bash-3.1_p16, baselayout-1.11.14-r8 and hotplug-20040923-r2 (among some others, but these packages are the most suspect).
The named pipes seem to be left over from the boot and shutdown according to their dates, and they are all owned by root.
In the meantime there are about 800 of them.

Bash creates such files when process substitution is used, but normally they are removed afterwards. I don't have a clue yet why they are not cleaned up.

hjnenc · Posted: Mon May 01, 2006 8:09 am Post subject:

I just found out that the named pipes are left over when process substitution is used inside command substitution, for example:

overkll · Posted: Tue May 02, 2006 4:20 pm Post subject:

I have 2 gentoo machines, yet only have this problem on one of them. Hmmm, strange.

Removing the /tmp/sh-np-* files and restarting "net.eth0" recreates the named pipe files in /tmp, 2 for each restarted daemon.

hjnenc · Posted: Tue May 02, 2006 4:30 pm Post subject:

That's interesting. What is the difference between the two machines?

overkll · Posted: Tue May 02, 2006 5:06 pm Post subject:

They are nearly identical. Both are Athlon64's and the same motherboard. The server runs amd64 (64bit) and my mythtv machine runs x86 (32bit). Server uses the onboard nic and the mythtv box uses a wireless card.

Your bug lists the arch as x86. My x86 works fine, but my amd64 has the issue with the leftover named pipes.

hjnenc · Posted: Fri May 05, 2006 6:38 pm Post subject:

Here is a workaround for this problem: reemerge bash with

overkll · Posted: Sat May 06, 2006 4:02 pm Post subject:

That did the trick for me. Thanks.

Funny, I only added the features userpriv and usersandbox to /etc/make.conf to get passed a error prone compile. I think it was gcc about a year ago.

Da Fox · Guru Joined: 06 Jul 2005 Posts: 341

so I guess this will be in the next update then?
_________________
"Man fears the darkness, and so he scrapes away at the edges of it with fire."
- Rei Ayanami

JGBE, a Java based GameBoy Emulator

hjnenc · Posted: Sat May 06, 2006 8:07 pm Post subject:

The fix is already in portage, just sync and reemerge bash.

lyallp · Posted: Sun Aug 20, 2006 10:25 pm Post subject: Works for me

Excellent, worked for me.

Although, I am curious, why didn't my regular 'emerge --udpate world' find it and rebuild bash?
_________________
...Lyall

hjnenc · Posted: Mon Aug 21, 2006 5:44 am Post subject: Re: Works for me

lyallp · Posted: Mon Sep 04, 2006 11:12 am Post subject:

This explains why I never received the update - and I am pretty rigorous with my updates.

Of course, the whole point of having versions is to capture precisely this issue, I am at a loss as to how we allowed a package to be updated without changing the version in some minor way (even a -r2 suffix would suffice).

I wonder how many other packages have this problem? (fixed with no version number changes)
_________________
...Lyall

hjnenc · Posted: Mon Sep 04, 2006 3:49 pm Post subject:

We are getting a bit off topic with this discussion, but I can also see reasons to do minor fixes without version bump. If only a few users benefit from it, why force all to do an update?

lyallp · Posted: Thu Sep 07, 2006 8:54 am Post subject:

Yep, bit off issue, but still based upon the root cause, why files left everywhere and not fixed by emerge updates.

I rigorously do my updates every day or so, precisely to get the fixes. I spent a reasonable amount of time trying to track down where these files came from - thinking it was one of my scripts or some package script before finding the answer in the forums.

Changing code without changing versions is just not done - you wouldn't have it happening in the kernel - people would scream - what makes the shell that basically drives the entire distribution any different?.

Regardless, it's fixed now, that's all that matters.
_________________
...Lyall

hjnenc · Posted: Thu Sep 07, 2006 4:49 pm Post subject:

I fully agree with you, that a version number should identify an exact version of the package. Every change, even a very small one, should result in a new version number. But the package version number in Gentoo is not only used for identification but also as a signal that users should do an upgrade. One has to do extra work to avoid the upgrade by putting the new version into the package.mask file.

I think it is this dual role of the version number that causes problems. I really don't like to recompile a large package (like openoffice) just because a spelling error in a comment in the ebuild was corrected. I admit, this is an extreme example, but where should be the border?

To come back to one of your earlier questions, in my experience it is rather often the case that packages are changed in some minor way without version bump. The first time I noticed that, I did not like it at all. In the meantime, I have changed my mind :wink:

lyallp · Posted: Fri Sep 08, 2006 9:48 am Post subject:

In response, I think that maybe emerge/portage requires a patch.

Maybe we should have an option that says 'do not upgrade unless it is a dot upgrade, any minus upgrades, ignore'

So, bash 3.1.16 (whatever, the numbers are ficticious) woud not be upgraded if portage had a bash 3.1.16--r1 update.

Another thought is that maybe portage should 'reserve -pr?' as being 'minor upgrades or e-build corrections'' and truncate software versions to avoid 'superfluous' builds

Regardless, I dislike this 'slipping a change in'. I would rather know that the change occurred and choose to ignore than not be told about it and spend time trying to solve a problem that should have been solved by my regular updates.
_________________
...Lyall