Linux find process executable

Linux find process by name

Procedure to find process by name on Linux

1. Open the terminal application.
2. Type the pidof command as follows to find PID for firefox process:
   pidof firefox
3. Or use the ps command along with grep command as follows:
   ps aux | grep -i firefox
4. To look up or signal processes based on name use:

pgrep firefox

Linux find process by name using pgrep command

pgrep command looks through the currently running processes and lists the process IDs which match the selection criteria to screen. All the criteria have to match. For example, will only list the processes called sshd AND owned by root user:
$ pgrep -u root sshd
Just look up pid for firefox process:
$ pgrep firefox

How to use ‘ps aux | grep command’

ps command shows information about a selection of the active processes:
$ ps aux
$ ps aux | grep -i ‘search-term’
$ ps aux | grep ‘firefox’
$ ps aux | grep ‘sshd’
OR use the following syntax instead of using egrep command in pipes:
$ ps -fC firefox
$ ps -fC chrome
The -C option asks ps command to select PIDs by command name.

• No ads and tracking
• In-depth guides for developers and sysadmins at Opensourceflare✨
• Join my Patreon to support independent content creators and start reading latest guides:
  • How to set up Redis sentinel cluster on Ubuntu or Debian Linux
  • How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
  • How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
  • A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
  • How to protect Linux against rogue USB devices using USBGuard

Join Patreon ➔

Using pidof command to grab PIDs for any named program on Linux

The pidof command finds the process id’s (pids) of the named programs such as sshd, firefox and more. For example:
$ pidof sshd
$ pidof firefox
Sample outputs:

A note about top/htop command

To display Linux processes use top command or htop command:
$ top
OR
$ htop

See also

Getting more help

Read the man pages for the following command using man command:
$ man pgrep
$ man pidof
$ man ps

🐧 Get the latest tutorials on Linux, Open Source & DevOps via

Источник

How find out which process is using a file in Linux?

I tried to remove a file in Linux using rm -rf file_name , but got the error:

How can I find out which process is using this file?

4 Answers 4

You can use the fuser command, like:

You will receive a list of processes using the file.

You can use different flags with it, in order to receive a more detailed output.

You can find more info in the fuser’s Wikipedia article, or in the man pages.

@jim’s answer is correct — fuser is what you want.

Additionally (or alternately), you can use lsof to get more information including the username, in case you need permission (without having to run an additional command) to kill the process. (THough of course, if killing the process is what you want, fuser can do that with its -k option. You can have fuser use other signals with the -s option — check the man page for details.)

For example, with a tail -F /etc/passwd running in one window:

Note that you can also use lsof to find out what processes are using particular sockets. An excellent tool to have in your arsenal.

For users without fuser :

Although we can use lsof, there is another way i.e., we can query the /proc filesystem itself which lists all open files by all process.

Sample output below:

l-wx——. 1 root root 64 Aug 15 02:56 /proc/5026/fd/4 -> /var/log/filename.log

From the output, one can use the process id in utility like ps to find program name

Источник

How can I find only the executable files under a certain directory in Linux?

How can I find only the executable files under a certain directory in Linux?

7 Answers 7

Checking for executable files can be done with -perm (not recommended) or -executable (recommended, as it takes ACL into account). To use the -executable option:

if you want to find only executable files and not searchable directories, combine with -type f :

Use the find’s -perm option. This will find files in the current directory that are either executable by their owner, by group members or by others:

I just found another option that is present at least in GNU find 4.4.0:

This should work even better because ACLs are also considered.

I know the question specifically mentions Linux, but since it’s the first result on Google, I just wanted to add the answer I was looking for (for example if you are — like me at the moment — forced by your employer to use a non GNU/Linux system).

Tested on macOS 10.12.5

I have another approach, in case what you really want is just to do something with executable files—and not necessarily to actually force find to filter itself:

I prefer this because it doesn’t rely on -executable which is platform specific; and it doesn’t rely on -perm which is a bit arcane, a bit platform specific, and as written above requires the file to be executable for everyone (not just you).

The -type f is important because in *nix directories have to be executable to be traversable, and the more of the query is in the find command, the more memory efficient your command will be.

Anyhow, just offering another approach, since *nix is the land of a billion approaches.

Источник

How do I get the path of a process in Unix / Linux

In Windows environment there is an API to obtain the path which is running a process. Is there something similar in Unix / Linux?

Or is there some other way to do that in these environments?

11 Answers 11

On Linux, the symlink /proc/

/exe has the path of the executable. Use the command readlink -f /proc/

/exe to get the value.

On AIX, this file does not exist. You could compare cksum and cksum /proc/

You can find the exe easily by these ways, just try it yourself.

gave me the location of the symbolic link so I could find the logs and stop the process in proper way.

| grep -m 1 txt , as the required process path info seems to be in the first line with txt , and not in the cwd line? (Applies on macOS and Ubuntu as of date of posting.)

A little bit late, but all the answers were specific to linux.

If you need also unix, then you need this:

EDITED: Fixed the bug reported by Mark lakata.

Replace 786 with your PID or process name.

This command will fetch the process path from where it is executing.

In Linux every process has its own folder in /proc . So you could use getpid() to get the pid of the running process and then join it with the path /proc to get the folder you hopefully need.

Here’s a short example in Python:

Here’s the example in ANSI C as well:

Compile it with:

There’s no «guaranteed to work anywhere» method.

Step 1 is to check argv[0], if the program was started by its full path, this would (usually) have the full path. If it was started by a relative path, the same holds (though this requires getting teh current working directory, using getcwd().

Step 2, if none of the above holds, is to get the name of the program, then get the name of the program from argv[0], then get the user’s PATH from the environment and go through that to see if there’s a suitable executable binary with the same name.

Note that argv[0] is set by the process that execs the program, so it is not 100% reliable.

The below command search for the name of the process in the running process list,and redirect the pid to pwdx command to find the location of the process.

Replace «abc» with your specific pattern.

Alternatively, if you could configure it as a function in .bashrc, you may find in handy to use if you need this to be used frequently.

Hope this helps someone sometime.

thanks : Kiwy
with AIX:

You can also get the path on GNU/Linux with (not thoroughly tested):

If you want the directory of the executable for perhaps changing the working directory to the process’s directory (for media/data/etc), you need to drop everything after the last /:

Источник

Search for executable files using find command

What type of parameter/flag can I use with the Unix find command so that I search executables?

10 Answers 10

On GNU versions of find you can use -executable :

For BSD versions of find, you can use -perm with + and an octal mask:

In this context «+» means «any of these bits are set» and 111 is the execute bits.

Note that this is not identical to the -executable predicate in GNU find. In particular, -executable tests that the file can be executed by the current user, while -perm +111 just tests if any execute permissions are set.

Older versions of GNU find also support the -perm +111 syntax, but as of 4.5.12 this syntax is no longer supported. Instead, you can use -perm /111 to get this behavior.

Tip of the hat to @gniourf_gniourf for clearing up a fundamental misconception.

This answer attempts to provide an overview of the existing answers and to discuss their subtleties and relative merits as well as to provide background information, especially with respect to portability.

Finding files that are executable can refer to two distinct use cases:

• user-centric: find files that are executable by the current user.
• file-centric: find files that have (one or more) executable permission bits set.

Note that in either scenario it may make sense to use find -L . instead of just find . in order to also find symlinks to executables.

Note that the simplest file-centric case — looking for executables with the executable permissions bit set for ALL three security principals (user, group, other) — will typically, but not necessarily yield the same results as the user-centric scenario — and it’s important to understand the difference.

User-centric ( -executable )

The accepted answer commendably recommends -executable , IF GNU find is available.

• GNU find comes with most Linux distros
  • By contrast, BSD-based platforms, including macOS, come with BSD find, which is less powerful.
• As the scenario demands, -executable matches only files the current user can execute (there are edge cases. [1] ).

The BSD find alternative offered by the accepted answer ( -perm +111 ) answers a different, file-centric question (as the answer itself states).

Using just -perm to answer the user-centric question is impossible, because what is needed is to relate the file’s user and group identity to the current user’s, whereas -perm can only test the file’s permissions.
Using only POSIX find features, the question cannot be answered without involving external utilities.

Thus, the best -perm can do (by itself) is an approximation of -executable . Perhaps a closer approximation than -perm +111 is -perm -111 , so as to find files that have the executable bit set for ALL security principals (user, group, other) — this strikes me as the typical real-world scenario. As a bonus, it also happens to be POSIX-compliant (use find -L to include symlinks, see farther below for an explanation):

gniourf_gniourf’s answer provides a true, portable equivalent of -executable , using -exec test -x <> \; , albeit at the expense of performance.

Combining -exec test -x <> \; with -perm +111 (i.e., files with at least one executable bit set) may help performance in that exec needn’t be invoked for every file (the following uses the POSIX-compliant equivalent of BSD find -perm +111 / GNU find -perm /111 ; see farther below for an explanation):

File-centric ( -perm )

• To answer file-centric questions, it issufficient to use the POSIX-compliant -perm primary (known as a test in GNU find terminology).
  • -perm allows you to test for any file permissions, not just executability.
  • Permissions are specified as either octal or symbolic modes. Octal modes are octal numbers (e.g., 111 ), whereas symbolic modes are strings (e.g., a=x ).
  • Symbolic modes identify the security principals as u (user), g (group) and o (other), or a to refer to all three. Permissions are expressed as x for executable, for instance, and assigned to principals using operators = , + and — ; for a full discussion, including of octal modes, see the POSIX spec for the chmod utility.
  • In the context of find :
    • Prefixing a mode with — (e.g., -ug=x ) means: match files that have all the permissions specified (but matching files may have additional permissions).
    • Having NO prefix (e.g. 755 ) means: match files that have this full, exact set of permissions.
    • Caveat: Both GNU find and BSD find implement an additional, nonstandard prefix with are-ANY-of-the-specified-permission-bits-set logic, but do so with incompatible syntax:
      • BSD find: +
      • GNU find: / [2]
    • Therefore, avoid these extensions, if your code must be portable.
• The examples below demonstrate portable answers to various file-centric questions.

File-centric command examples

• The following examples are POSIX-compliant, meaning they should work in any POSIX-compatible implementation, including GNU find and BSD find; specifically, this requires:
  • NOT using nonstandard mode prefixes + or / .
  • Using the POSIX forms of the logical-operator primaries:
    • ! for NOT (GNU find and BSD find also allow -not ); note that \! is used in the examples so as to protect ! from shell history expansions
    • -a for AND (GNU find and BSD find also allow -and )
    • -o for OR (GNU find and BSD find also allow -or )
• The examples use symbolic modes, because they’re easier to read and remember.
  • With mode prefix — , the = and + operators can be used interchangeably (e.g., -u=x is equivalent to -u+x — unless you apply -x later, but there’s no point in doing that).
  • Use , to join partial modes; AND logic is implied; e.g., -u=x,g=x means that both the user and the group executable bit must be set.
  • Modes cannot themselves express negative matching in the sense of «match only if this bit is NOT set»; you must use a separate -perm expression with the NOT primary, ! .
• Note that find’s primaries (such as -print , or -perm ; also known as actions and tests in GNU find) are implicitly joined with -a (logical AND), and that -o and possibly parentheses (escaped as \( and \) for the shell) are needed to implement OR logic.
• find -L . instead of just find . is used in order to also match symlinks to executables
  • -L instructs find to evaluate the targets of symlinks instead of the symlinks themselves; therefore, without -L , -type f would ignore symlinks altogether.

[1] Description of -executable from man find as of GNU find 4.4.2:

Matches files which are executable and directories which are searchable (in a file name resolution sense). This takes into account access control lists and other permissions artefacts which the -perm test ignores. This test makes use of the access(2) system call, and so can be fooled by NFS servers which do UID mapping (or root-squashing), since many systems implement access(2) in the client’s kernel and so cannot make use of the UID mapping information held on the server. Because this test is based only on the result of the access(2) system call, there is no guarantee that a file for which this test succeeds can actually be executed.

[2] GNU find versions older than 4.5.12 also allowed prefix + , but this was first deprecated and eventually removed, because combining + with symbolic modes yields likely yields unexpected results due to being interpreted as an exact permissions mask. If you (a) run on a version before 4.5.12 and (b) restrict yourself to octal modes only, you could get away with using + with both GNU find and BSD find, but it’s not a good idea.

Источник