fuser can show you ONLY if original file is in use.
fuser DOESN'T SHOW YOU IF SYMLINK IS IN USE which calls original file. That's the issue. You don't know if symlink unused and can be removed.
I have started two processes (24261 opened original file and 24262 opened symlink) :
root#server DEV # ls -l /lib64/libgcc_s-4.4.7-20120601.so.1
-rwxr-xr-x 1 root root 93320 Sep 1 2014 /lib64/libgcc_s-4.4.7-20120601.so.1
root#server DEV # ls -l /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
lrwxrwxrwx. 1 root root 20 Oct 19 2015 /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so -> /lib64/libgcc_s.so.1
root#server DEV #
root#server DEV # tail -f /lib64/libgcc_s.so.1 &
[1] 24261
root#server DEV #
root#server DEV # cd /usr/lib/gcc/x86_64-redhat-linux/4.4.4
root#server DEV # tail -f libgcc_s.so &
[2] 24262
root#server DEV #
root#server DEV # ps -ef | grep tail
root 24261 3265 0 13:39 pts/1 00:00:00 tail -f /lib64/libgcc_s.so.1
root 24262 3265 0 13:39 pts/1 00:00:00 tail -f libgcc_s.so
root 24492 3265 0 13:40 pts/1 00:00:00 grep tail
root#server DEV #
In both cases fuser tells that symlink and original file is in use (there are two processes for each command):
root#server DEV # fuser /lib64/libgcc_s.so.1
/lib64/libgcc_s.so.1: 24261 24262
root#server DEV # fuser /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so: 24261 24262
root#server DEV #
But we know that symlink was not used for the first process. It can be even removed and will not affect first process.
Let's say I want to remove 'gcc' package if the package is not in use.
Original file comes from 'libgcc' package.
root#server DEV # rpm -qf /lib64/libgcc_s.so.1
libgcc-4.4.7-11.el6.x86_64
Symlink comes from 'gcc' package:
root#server DEV # rpm -qf /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
gcc-4.4.7-11.el6.x86_64
If I will remove 'gcc' package which contains only symlink, I will affect second process! How I can see if symlink is unused?
In my case 'ps -ef' shows that I used command:
root 24262 3265 0 13:39 pts/1 00:00:00 tail -f libgcc_s.so
So ps cannot even tell you that symlink was used.
Any Linux guru?
EDITED:
There is partial solution checking cwd - current working directory:
root#server DEV # ls -l /proc/24262/cwd
lrwxrwxrwx 1 root root 0 Jun 20 13:57 /proc/24262/cwd -> /usr/lib/gcc/x86_64-redhat-linux/4.4.4
root#server DEV #
So from here you see the path "/usr/lib/gcc/x86_64-redhat-linux/4.4.4" and you can get file name from ps.
This doesn't work if you do:
root#server DEV # cd /root
root#server DEV # cat script.sh
/usr/bin/tail -f /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
root#server DEV #
root#server DEV # nohup ./script.sh &
[2] 26713
root#server DEV #
root#server DEV # ls -l /proc/26713/cwd
lrwxrwxrwx 1 root root 0 Jun 20 14:32 /proc/26713/cwd -> /root
It shows cwd for /root, but symlink is inside the script/program. So then you need to check ps chill process for /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so.
root#server DEV # ps -ef | grep 26713
root 26713 3265 0 14:32 pts/1 00:00:00 /bin/sh ./script.sh
root 26714 26713 0 14:32 pts/1 00:00:00 /usr/bin/tail -f /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgcc_s.so
root 26780 3265 0 14:38 pts/1 00:00:00 grep 26713
root#server DEV #
This is very confusing when you want to automate package removal (if the package is not in use).
It will be great if someone can see simpler way of this. Also if someone can confirm the accuracy of using cwd and ps child processes for symlink in use detection.
What will happen if script.sh would be binary file? Will I still able to see full symlink path in 'ps' or cwd?
Symlinks are not usual files: they cannot be opened with open() like regular files or directories. Symlink actually is just a constant string, which is automatically interpreted internally during path resolution.
Because of that symlinks are not "used" in the sence of utilities like fuser. When you call fuser for symlink, it actually shows info about file pointed by the link.
If by "in use" you mean "one or more programs is using the link as its path name for the file", then there is no way to tell. It could have been used yesterday, and it might be used tomorrow. Unix is designed so that, unless you are specifically using tools designed for that specific purpose, a symlink looks just like the file it points to. Programs like fuser or lsof will just go right through the links without even telling you it's a link.
If by "in use" you mean "points to a valid file", then there are ways to tell. The simplest being ls -L
$ ls -l foo
/bin/ls: cannot access foo: No such file or directory
$ ls -l g
lrwxrwxrwx 1 hymie users 3 2016-06-20 10:09 g -> foo
$ ls -lL g
/bin/ls: cannot access g: No such file or directory
Unfortunately, Linux kernel is designed to assign original file from the symlink in the start up phase. So when the process is running there is no possibility to check if file called directly or through symlink.
All you can do is to check what was current working directory ls -l /proc/<process_id>/cwd, command line arguments strings /proc/<process_id>/cmdline, what user started the process ps -ef | grep <process_id> then you can check user startup scripts and $PATH, ldd can show you which libraries are called from particular library. If you want to restart the process to see if symlink called then strace is your friend.
The premise of this question (identifying unused packages with fuser / lsof) is fundamentally flawed:
Not every file your system needs to work properly will referenced by an open file descriptor at any random time.
For example, you would have a bad time if you removed /bin/systemctl (since things like /sbin/shutdown are symlinks to it), but lsof shows nothing using it.
It's easy to come up with many more examples, like /bin/grep on my system. It's used all over the place in shell scripts, but I don't happen to have any long-running instances of it.
Related
I am trying to run a simple tcl script with tclsh8.6 that I compiled from source using a musl toolchain on x86_64 Debian.
The script, hello.tcl, looks like this:
puts hello
and when I try to run it I get the following error:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: No such file or directory
The necessary tcl libraries and include files are all installed to the prefix /usr/local/x86_64-linux-musl. The binary also exists:
$ ls -l /usr/local/x86_64-linux-musl/bin/tclsh8.6
-rwxr-xr-x 1 root root 8328 Nov 15 12:18 /usr/local/x86_64-linux-musl/bin/tclsh8.6
$ ldd /usr/local/x86_64-linux-musl/bin/tclsh8.6
linux-vdso.so.1 (0x00007ffd04718000)
libtcl8.6.so => /usr/local/x86_64-linux-musl/lib/libtcl8.6.so (0x00007f005981e000)
libc.so => /usr/local/x86_64-linux-musl/lib/libc.so (0x00007f0059587000)
I would like to keep things musl based, so I am trying to avoid a potential solution I found elsewhere, which is to reinstall tcl or tcl-dev with apt-get.
What is causing this error? Any guidance/help is greatly appreciated. Thanks :)
EDIT
As requested by some of the comments here is some additional information.
The output of the file command:
$ file /usr/local/x86_64-linux-musl/bin/tclsh8.6
/usr/local/x86_64-linux-musl/bin/tclsh8.6: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, not stripped
The output of the strace command:
strace /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
execve("/usr/local/x86_64-linux-musl/bin/tclsh8.6", ["/usr/local/x86_64-linux-musl/bin"..., "hello.tcl"], 0x7fffb8c5b278 /* 19 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++
After seeing this output, I checked to see if the loader/interpreter existed at /lib and it didn't. To fix this, I ran:
$ sudo ln -s /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1
That gave me a different error when I ran tclsh8.6:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
Running it with sudo gives the same thing:
$ sudo /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
sudo: unable to execute /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
The permissions on the interpreter and script are as follows:
$ ls -l /usr/local/x86_64-linux-musl/bin/tclsh8.6
-rwxr-xr-x 1 root root 8328 Nov 15 13:34 /usr/local/x86_64-linux-musl/bin/tclsh8.6
$ ls -l hello.tcl
-rwxr-xr-x 1 user user 11 Nov 15 12:44 hello.tcl
Hopefully this new information helps a bit more.
EDIT 2
More permission information :)
$ ls -l /lib/ld-musl-x86_64.so.1
lrwxrwxrwx 1 root root 52 Nov 16 10:04 /lib/ld-musl-x86_64.so.1 -> /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
$ ls -l /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
lrwxrwxrwx 1 root root 12 Nov 15 12:02 /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 -> /lib/libc.so
$ $ ls -l /lib/libc.so
-rw-r--r-- 1 root root 246 Nov 14 15:15 /lib/libc.so
And here is the contents of /lib/libc.so:
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( //lib/libc.so.6 //lib/libc_nonshared.a AS_NEEDED ( //lib/ld-linux-x86-64.so.2 ) )
It is a linker script, which if you make executable fails and says the library is corrupted.
With the help of #Shawn I was able to figure out my problem.
tclsh8.6 was looking for the program interpreter at /lib/ld-musl-x86_64.so.1 which didn't exist - I guess when I was installing musl-cross-make it didn't set this up. To fix this problem, I simply symlinked from where ld-musl-x86_64.so.1 was located to lib:
$ sudo ln -s /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1 /lib/ld-musl-x86_64.so.1
However, I still was getting an error, but this time it was a permissions error:
$ /usr/local/x86_64-linux-musl/bin/tclsh8.6 hello.tcl
-bash: /usr/local/x86_64-linux-musl/bin/tclsh8.6: Permission denied
It turns out that ld-musl-x86_64.so.1 ended up being a symlink that resolved to /lib/libc.so which is a linker script and not the executable DSO that we want. I changed this symlink accordingly:
sudo ln -fs /usr/local/x86_64-linux-musl/lib/libc.so /usr/local/x86_64-linux-musl/lib/ld-musl-x86_64.so.1
After that, I could execute my script and everything worked like a charm! :)
Say someone runs htop with sudo:
$sudo htop
I know we can get the user name of the htop process by:
$ps aux | grep htop
But in this case it only returns root as the username:
$ps aux | grep htop
root 21186 0.0 0.0 71256 4148 pts/2 S+ 17:16 0:00 sudo htop
root 21187 2.6 0.0 31460 5128 pts/2 S+ 17:16 0:21 htop
How can I find out which user is behind root?
This might work for you. It grabs the commands executed with sudo from /var/log/auth.log:
awk '/sudo/&&/COMMAND/ {
print gensub(/sudo: ([^ ]*).*USER=([^ ]*).*COMMAND=([^ ]*)/,
"\\1 (as \\2) command: \\3", 1)
}' /var/log/auth.log
Simply use grep on /var/log/secure or /var/log/auth.log (depends on the distro):
$ sudo grep sudo /var/log/secure
(or)
$ sudo grep sudo /var/log/auth.log
If these two doesn't work then use sudo journalctl _COMM=sudo
It will give output as:
Apr 14 00:23:35 hell-abhi sudo[14519]: hell_abhi : TTY=pts/1 ; PWD=/home/hell_abhi ; USER=root ; COMMAND=/bin/journalctl _COMM=sudo
Apr 14 00:21:43 hell-abhi sudo[14348]: hell_abhi : TTY=pts/0 ; PWD=/home/hell_abhi ; USER=root ; COMMAND=/bin/nano
The table shows: date, time, user, pid, teminal, directory, command used.
Here you can see: hell_abhi ran sudo nano from /home/hell_abhi(his home directory).
How can I find all files contains specific string from root level?
I've looged with root & tried something like:
[root#ip-172-18-7-96 /]# grep -r 'log4j' /
grep: /proc/sys/fs/binfmt_misc/register: Invalid argument
grep: /proc/sys/net/ipv4/route/flush: Permission denied
I get just several permission denied (although I'm root).
As root, you can still chmod a-r file:
$ ls -la /proc/sys/net/ipv4/route/flush
--w------- 1 root root 0 Sep 4 15:59 /proc/sys/net/ipv4/route/flush
On Apache 2.2 on CentOS 6.4 with perl 5.10.1.
I'm trying to get a remote directory listing from within a mod_perl script, which apparently (if I die qx(id)) is running as apache. But I'm not even getting as far as being able to run ssh without parameters, just to have it print its help info. So that's what I'm asking how to do in this question--it's not about ssh not being able to connect.
die qx(which ssh);
dies with:
/usr/bin/ssh
and:
die qx(ls -al /usr/bin/ssh);
dies with:
-rwxr-xr-x. 1 root root 376920 Feb 21 2013 /usr/bin/ssh
Okay, so, it can find it, and see it, and has execute rights on it (which is true for /usr/bin and /usr as well.) But then:
die qx(/usr/bin/ssh); # or just 'ssh'
dies with an empty array, so I tried:
system("ssh") == 0 or die "failed: $! (code $?)"; # or '/usr/bin/ssh'
...which dies with:
No such file or directory (code 65280)
Why is this? How can I get die qx(ssh) or die qx(/usr/bin/ssh) to die with the expected value of:
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-W host:port] [-w local_tun[:remote_tun]]
[user#]hostname [command]
Interestingly, from a bash prompt I get this:
$ sudo su apache ssh
This account is currently not available.
So...how can I run ls from an account that's not available, yet not ssh? They're both programs, why do they behave differently here?
Update: It's not just ssh, but I can't figure out the pattern: gawk, tar, and ping also don't work. Yet df, ls, dir, and pwd all do. But:
$ ls -al /bin/ls
-rwxr-xr-x. 1 root root 109208 May 23 07:00 /bin/ls
$ ls -al /usr/bin/dir
-rwxr-xr-x. 1 root root 109208 May 23 07:00 /usr/bin/dir
$ ls -al /bin/pwd
-rwxr-xr-x. 1 root root 28008 May 23 07:00 /bin/pwd
$ ls -al /bin/df
-rwxr-xr-x. 1 root root 73808 May 23 07:00 /bin/df
$ ls -al /bin/gawk
-rwxr-xr-x. 1 root root 375360 Aug 7 2012 /bin/gawk
$ ls -al /bin/tar
-rwxr-xr-x. 1 root root 390616 Feb 21 2013 /bin/tar
$ ls -al /usr/bin/ssh
-rwxr-xr-x. 1 root root 376920 Feb 21 2013 /usr/bin/ssh
$ ls -al /bin/ping
-rwsr-xr-x. 1 root root 40760 Jun 5 06:39 /bin/ping
So they all have all the 'x' bits set (except ping with its one 's', yet see below its error code), and for example, ssh and dir have identical ACLs. So why should ssh and gawk fail to give any output but dir and ls succeed? (Full paths or no.)
Update: even more perplexingly, /bin/gawk fails with the same message but code 256, and /bin/tar and /bin/ping similarly but code 512.
Update: OK, this part makes sense: If I run the failing binaries from the command line and then run echo $? immediately after, ssh gives 255, ping and tar give 2, and gawk gives 1. Those are scaled-down versions of what I get in mod_perl2. So, it seems to be that anything with a return code other than 0 doesn't work. Possibly it's outputting to STDERR, and so STDOUT doesn't capture anything, hence the blank return.
Aha, that's the answer--will post.
If you redirect STDERR to also capture it in your qx, like so:
die qx(ssh 2>&1);
...you'll get the output you get on the command line. So it's not that it's not running, it's just that it doesn't write anything to STDOUT.
Is there a way to find what path a command has had it's output redirected to (if it has been)?
I tried using:
ps -p PID -o cmd
Thinking I could look for a > and extract the path from that, but the output doesn't have that part in it. I'm pretty sure it hasn't just been truncated.
You can use the proc file system /proc/self/fd for this
readlink /proc/self/fd/1
for stdout or 2 for stderr.
If you know the PID, just inspect /proc/ID/fd/1. It should be linked to the actual path:
$ watch date > /tmp/1 &
[1] 27346
$ ls -l /proc/27346/fd/1
l-wx------ 1 choroba users 64 2013-02-15 16:28 /proc/27346/fd/1 -> /tmp/1
Use the lsof (list open files) command to see what files a process has open for writing.
For example:
$ lsof -p 31714
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
bash 31714 dogbane 0u CHR 136,4 6 /dev/pts/4
bash 31714 dogbane 1w REG 8,1 15 2032202 /tmp/t
The w in the FD (file descriptor) column means that /tmp/t is open for writing.
How about it?
[root#us04 ~]# ls -l /proc/14170/exe
lrwxrwxrwx 1 root root 0 Feb 15 10:36 /proc/14170/exe -> /usr/sbin/httpd
One more example:
[root#us04 ~]# readlink -f /proc/5352/exe
/sbin/syslogd