Tag Info

New answers tagged

0

It seems that you are talking about leak of your user space program. For this, I would suggest following : Check /proc/PID_OF_YOUR_PROCESS/status file carefully and periodically. This file will show all the information your process that you may be interested. In above file you would be interested in VmSize (total program size) and VmRSS (size of memory ...


5

Yes, that's the PID of ls. POSIX defined ls as an external command, so anytime you run ls, the shell must create new process and run ls in that process. To do that, the shell will call execve() system call: $ strace ls -l /proc/self execve("/bin/ls", ["ls", "-l", "/proc/self"], [/* 76 vars */]) = 0 You can see, after new process was created, /proc/self ...


7

Yes, it's the PID of ls: /proc/self This directory refers to the process accessing the /proc file system, and is identical to the /proc directory named by the process ID of the same process. (from man 5 proc) /proc/self is a symbolic link to /proc/PID for the PID of the process that accesses the link, by the magic of the proc filesystem. In your ...


2

If your system uses PAM (most do), you can use the pam_exec module in the session stack. Note that the user won't be logged in until the command finishes; if you want to run something in the background, fork it. Several environment variables provide information about the session. For example: session optional pam_exec.so seteuid ...


1

In the /etc/sudoers file (shortcut visudo) add these lines: Cmnd_Alias CMDNAME = /path/to/binaryOrscriptToBeRunAsRoot %groupnamehere ALL=NOPASSWD: CMDNAME Instead of using a username only, creating a CMDNAME group and all users in that group have that permission: groupadd groupnamehere usermod -G groupnamehere usertoaddtogrouphere To test this, ...


1

netstat itself does not support such filtering. You probably have to do something like: sudo netstat -lp --inet | grep " $pid/"


2

PIDs increment by one except specific patches like gr-security. If you see an increment by steps of 4, this is probably due to your shell executing some extra commands everytime, for example through the $PROMPT_COMMAND variable.


3

PIDs are increased by one. Start two shells. shell 1 echo $$ # we assume 1234 as output shell 2 strace -f -p 1234 -e trace=clone shell 1 sleep 1 ; sleep 1 shell 2 # output like clone(Process 25484 attached child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f4111a029d0) = 25484 [pid 25484] +++ exited with 0 +++ ...


2

It doesn't as much "get" CPU, as it just runs on it. The kernel decides on which core and when and for how long the process runs. It schedules the tasks so that each process gets its time slices on the CPU: it runs for a while, then either after the time slice expires, or a system call occurs, the context is switched to another process. The state of the ...


1

CPU A process can lower its CPU priority (but not decrease it, man 2 setpriority). Furthermore it can put itself to sleep for a certain time. But it cannot decide how the CPU time it saves is given to other processes. For the situation with threads see psusi's comment. memory A new process gets an initial amount of RAM (I don't know, though, whether this ...


2

> strace -c -f -e trace=fork,vfork,clone,execve,execl bash -c 'ls -ld /etc;sleep 1' Process 15683 attached drwxr-xr-x 1 root root 5540 10. Jan 02:08 /etc Process 15684 attached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 0.00 0.000000 0 2 ...


0

Three answers written in 2014, all saying that in Unices and in Linux the process is reparented to process #1 without exception. Three wrong answers. ☺ As the SUS says, quoted in one of the other answers here so I won't quote it again, the parent process of orphaned children is set to an implementation-defined process. Cristian Ciupitu is right to ...


3

The proces is already dead at the time. It doesn't make sense to kill it again. It is still recorded in the process table to allow the parent ti pick up its status. Note that all processes become zombies after being killed. You just don't see them because most parent processes clean up their children very quickly. You might want to file a bug report if a ...


2

Consider this thought experiment: if ps ran to completion before invoking grep as you think it should, that would mean that the shell would need to: Invoke ps. Buffer all of its output (because it has nowhere else to go yet). Invoke grep. Feed the saved output to grep's stdin. This is wasteful; it's a more efficient use of memory to invoke grep first, ...


1

Just confirming as BowlOfRed and alexises stated. Here is a visual representation piping ps and grep back to ps again to show how the piped processes run. Note that the final ps x --forest is ignoring the input, but it keeps the previously piped processes alive so they will be displayed. ps -ef | grep myprocess | ps x --forest Excerpt of output: 25056 ...


6

When I'm only interested in presence of a process, I use pgrep which doesn't show this behaviour, e.g.: $ pgrep myprocess 1900 In other cases (when i'm interested in more info), I usually add a '| grep -v grep' to discard grep lines, e.g.: $ ps -ef | grep myprocess| grep -v grep hth.


10

This behavior is totally normal, it's due to how bash manages pipe usage. pipe is implemented by bash using the pipe syscall. After that call, bash forks and replaces the standard input (file descriptor 0) with the input from the right process (grep). The main bash process creates another fork and passes the output descriptor of the fifo in place of the ...


6

The pipe does not behave like ;. It starts both the processes together. Which is why the grep command showed up too. So when you gave ps aux | grep myprocess , the ps aux included the grep myprocess, so the grep included that in its output. To check this, I gave two dd commands on my test server like this: [sreeraj@server ~]$ dd if=/dev/urandom ...


3

You're correct, that's not how it works. The shell doesn't wait for the first process in a pipeline to exit before starting the next. It starts them all. As such, the ps may see the grep already running.


1

This means that the service incrond crashed or got killed forcefully. When a service is started, it touches a lock file (normally at /var/lock/subsys). This lock file is removed only when the service is stopped. When the service/program crashes, it will not get 'the chance' to remove the lock file and in such a situation, even though the service won't be ...


0

In case anyone still looks at this issue, seems to me that it could be related to this reported bug: https://groups.google.com/forum/#!topic/linux.kernel/GbafDHrvrxE http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=timers-urgent-for-linus&id=5a8e01f8fa51f5cbce8f37acc050eb2319d12956 Therefore only affecting older kernels.


2

Why don't we try it out and see? Here's a trivial program using signal(3) to trap SIGINT in both the parent and child process and print out a message identifying the process when it arrives. #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> void parent_trap(int sig) {fprintf(stderr, "They got back ...



Top 50 recent answers are included