Today's article has you listing open files...

[KGIII]

It's not a particularly useful command for most of us, but have you ever wanted to list all the currently open files (it's a lot)?

Well, have you ever wanted to list the currently open files in the terminal?

Have you ever wanted to list all the files opened by a specific user - or by everyone else except a specific user?

You can do that!

How To: List Open Files • Linux Tips

Today's article might seem unimportant and that's okay because we're just going to examine one way to list often files. Read on to list open files!

linux-tips.us

Of course, it's worth mentioning that Linux treats everything like a file. For a full operating system in running condition, this means there are a whole lot of files open. So, have fun with this one? I dunno... I haven't really found much use for the command, but now you know...

 

[dos2unix]

Have you done ssh-key password-less logins?

 

[KGIII]

Have you done ssh-key password-less logins?

There's this guest article, by a forum member whose username might seem familiar:

Guest Article: What Are SSH Keys? • Linux Tips

The following article is a guest-written article from Andy Brooks (aka captain-sensible) about SSH keys.

linux-tips.us

 

[osprey]

KGIII, as you mention in the article, lsof is "useful for things like auditing or troubleshooting". An example of it's usefulness in troubleshooting was in relation to sound problems in my case during the transition in the system from pulseaudio to pipewire. During the process it was useful to check repeatedly with lsof to check what was controlling the sound devices. Pulseaudio hung on tenaciously, which was only evident by the lsof output, until after some final configurations that showed success with output such as from this command:

[[email protected] ~]$ lsof /dev/snd/*
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pipewire  1125  flop   46u   CHR  116,1      0t0  350 /dev/snd/seq
pipewire  1125  flop   47u   CHR  116,1      0t0  350 /dev/snd/seq
wireplumb 1126  flop   25u   CHR 116,16      0t0  606 /dev/snd/controlC0
wireplumb 1126  flop   27u   CHR 116,10      0t0  567 /dev/snd/controlC1

Another great feature of lsof is the information it provides as to which files are being activated of a particular program one is using. For example, if one uses the PID of an xterm command and runs it in lsof, like:

lsof -p <PID-of-xterm>

the output is a list of files involved in running that xterm. I'll leave the output for the reader to discover since its quite lengthy, but very informative I think if one's interested.

On the matter of "everything is a file in linux", (which is slightly different to "linux treats everything like a file") it's almost like that, but a few things escaped, like ethernet and wifi.They are themselves.

 

[KGIII]

KGIII, as you mention in the article, lsof is "useful for things like auditing or troubleshooting".

Yeah, as mentioned, it's useful for that - though I don't see too many folks digging that direction. In all the years I've been doing this, I think I've recommended lsof once or twice and seen about the same number of questions.

On the matter of "everything is a file in linux", (which is slightly different to "linux treats everything like a file") it's almost like that, but a few things escaped, like ethernet and wifi.They are themselves.

I could probably make that more clear. In fact, I could probably turn that into an entire article. I might cheat and let AI handle much of it, assuming it answers correctly. I've found AI useful for two articles but not so much otherwise.

 

[osprey]

I might cheat and let AI handle much of it, assuming it answers correctly. I've found AI useful for two articles but not so much otherwise.

Fortunately, the ChatGPT AI is reluctant to provide opinions and evidently tries to stick to the facts, so it supposedly won't replace good advice based on opinion from experienced practitioners in any field. And even if it did provide opinions, since those can differ infinitely, it's still confined to a considerable limitation.

I'm reminded of the advice in an old book on UNIX which went something along the lines of "you don't understand something (in system administration) until you've implemented it", which is referencing in part the coming to terms with the nuances, subtleties and idiosyncrasies of a lot of software, and the fact that there are often numerous solutions to the same problem, and that often opinions differ in relation to each of them.

 

[KGIII]

I'm reminded of the advice in an old book on UNIX which went something along the lines of "you don't understand something (in system administration) until you've implemented it", which is referencing in part the coming to terms with the nuances, subtleties and idiosyncrasies of a lot of software, and the fact that there are often numerous solutions to the same problem, and that often opinions differ in relation to each of them.

This is one of the reasons why so many of my articles come from notes I've kept over the years. Another source for articles is something I've recently had to do.

Even still, I learn a whole lot while writing these. I uncover things I never knew before - even when going through my notes. I initially thought my notes were pretty exhaustive - as I've been keeping them in various text files for many, many years. Nope... Often, stuff will have changed and there's just plain new stuff that I uncover while researching and testing.