Hide

What's this?

commandlinefu.com is the place to record those command-line gems that you return to again and again.

Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.


If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/

Get involved!

You can sign-in using OpenID credentials, or register a traditional username and password.

First-time OpenID users will be automatically assigned a username which can be changed after signing in.

Hide

Stay in the loop…

Follow the Tweets.

Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.

» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10

Subscribe to the feeds.

Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):

Subscribe to the feed for:

Hide

News

2011-03-12 - Confoo 2011 presentation
Slides are available from the commandlinefu presentation at Confoo 2011: http://presentations.codeinthehole.com/confoo2011/
2011-01-04 - Moderation now required for new commands
To try and put and end to the spamming, new commands require moderation before they will appear on the site.
2010-12-27 - Apologies for not banning the trolls sooner
Have been away from the interwebs over Christmas. Will be more vigilant henceforth.
2010-09-24 - OAuth and pagination problems fixed
Apologies for the delay in getting Twitter's OAuth supported. Annoying pagination gremlin also fixed.
Hide

Tags

Hide

Functions

truncate deleted files from lsof

Terminal - truncate deleted files from lsof
lsof|gawk '$4~/txt/{next};/REG.*\(deleted\)$/{printf ">/proc/%s/fd/%d\n", $2,$4}'
2014-03-11 10:40:32
User: wejn
Functions: gawk
1
truncate deleted files from lsof

While the posted solution works, I'm a bit uneasy about the "%d" part. This would be hyper-correct approach:

lsof|gawk '$4~/txt/{next};/REG.*\(deleted\)$/{sub(/.$/,"",$4);printf ">/proc/%s/fd/%s\n", $2,$4}'

Oh, and you gotta pipe the result to sh if you want it to actually trim the files. ;)

Btw, this approach also removes false negatives (OP's command skips any deleted files with "txt" in their name).

Alternatives

There are 2 alternatives - vote for the best!

Terminal - Alternatives
lsof | grep -i deleted | grep REG | grep -v txt | ruby -r 'pp' -e 'STDIN.each do |v| a = v.split(/ +/); puts `:> /proc/#{a[1]}/fd/#{a[3].chop}`; end'
2014-03-11 06:02:09
User: jim80net
Functions: grep
0

Be careful, first run:

lsof | grep -i deleted | grep REG | grep -v txt

Then, give it the boot!

Know a better way?

If you can do better, submit your command here.

What others think

Now there are two versions of this command, but neither of you have explained WHY you'd do this.

Deleted doesn't necessarily mean not-in-use.

Lots of programs create then immediately delete temporary files, but keep a handle to them (to continue working).

That means when the program closes, the files automatically disappear.

Comment by flatcap 19 weeks and 1 day ago

@flatcap I figured jim80net had a reason for writing a thing like this. I merely took it as an exercise to make the one-liner more effective (and hopefully free of false negatives).

As for the reason why you might want to do that... well, suppose you have a network server written in a garbage collected language (i.e. Java). The said server has a strong ref that prevents it from releasing a (now useless) fd. Perhaps a reference leak of some kind. So even if you delete the file it still doesn't free the resources allocated by that file (since there's open fd in the system). Truncating the file via /proc/$pid/fd/$fdno frees the allocated blocks... and allows you to keep the abovementioned server running (if you don't mind a stray open fd).

Now, in my 15+ year career I've only used something akin to this a handful of times... but it sometimes happens that you really need to free allocated blocks from already deleted file without killing some kind of a service.

It's not an everyday task... but i'd say that if you play long enough with UN*Xes, you're bound to stumble upon a situation that calls for this.

Comment by wejn 19 weeks and 1 day ago

@wejn: Thanks for the reply.

It's the sort of command that shouldn't be necessary... :-)

Comment by flatcap 19 weeks and 1 day ago

My only comment is '{printf ">/proc/%s/fd/%d\n", $2,$4}' should be '{printf ":>/proc/%s/fd/%d\n", $2,$4}'

I agree with flatcap as well, it's usually only called for from misbehaving or misconfigured programs. Next time I need it though, I'll use wejn's version, as I'm impressed by the gawk foo! =]

Comment by jim80net 19 weeks and 1 day ago

@jim80net for bash ">file" works the same as ":>file". And I'm actually not fond of the latter, because ":" could be aliased or defined as some function.

Reminds me of the notorious:

:(){ :|:& };:

fork bomb I'm wearing on my t-shirt. ;)

If I had to stick something before the ">" character I'd probably go with /bin/true. ;)

YMMV, though.

Comment by wejn 19 weeks ago

Your point of view

You must be signed in to comment.

Related sites and podcasts