How might it be possible to alter some variable in the env of an already running process, for example through /proc/PID/environ? That "file" is read-only. Need to change or unset the DISPLAY variable of a long-running batch job without killing it.

Let's say we have a CPU-intensive application called multi-threaded-application.out that is running on top of Ubuntu with a PID of 10000. It has 4 threads with tid 10001, 10002, 10003, and 10004. I want to know, at any given time, on which core each of these threads is being scheduled? I tried /proc//tasks//status, but I couldn't find any information regarding the core ID that is responsible for running the given thread. This question is somehow related to this one . Any help would be much appreciated.

I am using OpenBSD 7.7. So I know that procfs is not mounted on /proc, and I need to use sysctl to fetch process maps. But this fails as I am not running as a root user. The secure level is set to 1 so that is why I can't use sysctl without root. But even procmap is not permitted as a root user. Is there any way I can fetch the process maps without root?

Running the following command generates different random output on each execution (which is expected, considering that random is in the path): cat /proc/sys/kernel/random/uuid Is there any way to modify the path so that it results in a static (not random) UUID on each call (return the same thing on each request/execution instead of being random)?

Under Linux/Ubuntu: I had an impression that to have video output (either in console mode or GUI mode), there must be a fbdev listed in /proc/fb. But today on my system, I installed a NVIDIA GTX1650 card, and under /etc/modprobe.d, the options nvidia-drm modeset=1 and options nvidia-drm fbdev=1 are disabled. After reboot, the system shows that /proc/fb is empty, but the X11/Gnome desktop is showing up correctly. I guess I must have a mis-understanding of the implications of /proc/fb content. Can you please give me some hints on that?

The window of my text editor Xed froze with Unsaved documents just as I was doing 'File'->'Save as...' to save them... [How ironic.] Since the process still exists, I am trying to recover the text of those documents from the process memory (/proc/$pid/mem). [There was quite some text, thus the effort.] I first tried through the following bash script based on

taken from this page :

#!/bin/bash

if [ -z "$1" ]; then
  echo "Usage: $0 "
  exit 1
fi
if [ ! -d "/proc/$1" ]; then
  echo "PID $1 does not exist"
  exit 1
fi

while read -r line; do
  mem_range="$(echo "$line" | awk '{print $1}')"
  perms="$(echo "$line" | awk '{print $2}')"

  if [[ "$perms" == *"r"* ]]; then
    start_addr="$(echo "$mem_range" | cut -d'-' -f1)"
    end_addr="$(echo "$mem_range" | cut -d'-' -f2)"

    echo "Reading memory range $mem_range..."
    dd if="/proc/$1/mem" of="/dev/stdout" bs=1 skip="$((16#$start_addr))" count="$((16#$end_addr - 16#$start_addr))" 2>/dev/null
  fi
done < "/proc/$1/maps"

The script outputs some data, however I am dubious about the approach because: - I get this error/warning message due to the

part:

: /proc/4063214/mem: cannot skip to specified offset

and I have then read somewhere that since

/proc/$pid/mem

is a virtual file it cannot be skipped. - The first comment in this post says that

cannot be used, however... (i) the comment is quite ancient by now, so I am wondering if it is still valid, (ii) despite the

skip to specified offset

warning message from

it appears that shifting the offset value shifts the output accordingly, and (iii) with

I recover the same data as with

mentioned in this other answer ). So, should

be working in the end? - Still under the same post, someone mentioned the

command which can generate a 'core file' of a process. Howerver, I am not sure what is a 'core file' and if this is what I need. My questions are: - Is using the

command as in the script above a valid path in the end? - Should I rather stick to the Python-based approach proposed in this post mentioned above? (Or some other method like the gcore command?) - Would there be some alternative path to my issue using other files from the '/proc/$pid' folder of Xed?

I noticed that according to /proc/net/dev I am constantly receiving around 6Kb/s on my wireless usb interface. But I can't account for anything even close to that with the individual connections that I get with iptraf, iftop, and nethogs. Investigations with netstat, lsof, and tcpdump didn't help either. So, what else could contribute to /proc/net/dev values? I can speculate that, while only IP based traffic is reported by the applications I mentioned, /proc/net/dev probably accounts for other link-layer/internet-layer stuff too (arp? icmp? wireless management stuff?). Or maybe other transport/application protocols. Can anyone confirm this? How else would you proceed to find out: through what sockets are the 6Kb/s coming through? What processes are receiving the traffic? --- [EDIT] The 2 consistent results across all the tools: 1. the totals of Rx are around a few Kb/s - confirmed with /proc/net/dev, dstat, bmw-ng, cbm, iptraf, ifstat, gnome-system-monitor 2. no connection/packet stream justifies that - confirmed with netstat, tcpdump, iftop, nethogs, iptraf All of this with a Netgear WDNA 4100 wireless usb adapter using a custom driver from some git (the only way I got it to work). I asked the devs about it [here](https://github.com/ashaffer/rt3573sta/issues/9) . This might be malware, but I suspect the driver is simply reporting wrong totals. Nevertheless, I cannot explain what's going on for sure.

I have sshd with PID of 1957: mohsen@debian:~$ ps ax -o pid,nice,pri,cmd |grep 1957 1957 -2 21 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups According to above, my nice number is -2 and pri number is 21.
According to /proc/1957, I can't find my nice number and pri number.
root@debian:~# cd /proc/1957 root@debian:/proc/1957# cat sched sshd (1957, #threads: 1) ------------------------------------------------------------------- se.exec_start : 211942985.934983 se.vruntime : 31.031644 se.sum_exec_runtime : 23.385935 se.nr_migrations : 14 nr_switches : 57 nr_voluntary_switches : 18 nr_involuntary_switches : 39 se.load.weight : 1624064 se.avg.load_sum : 4366 se.avg.runnable_sum : 4470824 se.avg.util_sum : 1557504 se.avg.load_avg : 147 se.avg.runnable_avg : 95 se.avg.util_avg : 33 se.avg.last_update_time : 211909716609024 se.avg.util_est : 38 policy : 0 prio : 118 clock-delta : 89 mm->numa_scan_seq : 0 numa_pages_migrated : 0 numa_preferred_nid : -1 total_numa_faults : 0 current_node=0, numa_group_id=0 numa_faults node=0 task_private=0 task_shared=0 group_private=0 group_shared=0 Where in /proc are the number pri and nice stored?

I'm using the pidstat to monitor the cpu usage of a process and it shows 100%. For the same process the htop or top shows 200% for the same process. The system has 16 cores, and the process i am monitoring was set to use only two cores. So the htop or top reported %CPU is correct. I also changed the process to use only one core and in that case also pidstat shows 100% cpu and htop shows 100% Is pidstat measures the %CPU differently?

I need to know if a process with a given PID has opened a port without using external commands. I must then use the /proc filesystem. I can read the /proc/$PID/net/tcp file for example and get information about TCP ports opened by the process. However, on a multithreaded process, the /proc/$PID/task/$TID directory will also contains a net/tcp file. My question is : do I need to go over all the threads net/tcp files, or will the port opened by threads be written into the process net/tcp file.

Say I have a pid in hand, $pid. Is there some bash/system command I can use to listen for the exit of that process with the given pid? If no process with $pid exists, I guess the command should simply fail.

My /proc/cpuinfo says my processor is 800Mhz, when I know the thing is actually 2.8Ghz. This is due to idle throttling where the cpu clock is slowed when idle to save power. Is there a way in Linux to find the **true** cpu speed?

I've set computer hostname in /etc/hostname a while ago (also there are record in /etc/hosts). Everything worked fine, but recently I've noticed that value of hostname (and /proc/sys/kernel/hostname) changed (to hostname of neighbour computer), although I haven't touched anything related. Value of /etc/hostname remains correct. Which mechanism may cause such change? There are similar problem description , but it doesn't contains any solution.

I'm running the following C program

// hello.c

#include 
#include 

int main() {
  while (1) {
    printf("Hello\n");
    fflush(stdout);
    sleep(1);
  }

  return 0;
}

I launched the program using

./hello

and I can see on the terminal its messages. Then I get its pid using. However if I do

tail -f /proc//fd/1

I do not get anything. Ditto if I use

cat /proc//fd/1

I think that I probably misunderstood some concepts about stdout and /proc. It is possible to do what I'm trying to do?

If I examine /proc/1/environ I can see a null-byte-delimited string of process 1's environment variables. I'd like to bring these variables into my current environment. Is there an easy way to do this? The proc man page gives me a snippet which helps be print out each environment variable on a line-by-line basis (cat /proc/1/environ; echo) | tr '\000' '\n'. This helps me verify the contents are correct, but what I really need to do is source these variables into my current bash session. How do I do that?

/proc/meminfo has a memory statistic VmallocTotal. It is described as > Total size of vmalloc memory area. in [proc's man page](https://man7.org/linux/man-pages/man5/proc.5.html) and elsewhere as > Total memory available in kernel for vmalloc allocations It sparked my curiosity because it is a very high number and everywhere I searched it is exactly 34359738367 kB. It seems like an arbitrary maximum. But what is the significance of 34359738367 kB? It is not a multiple of 2, not a prime number, but it is 0x7FFFFFFFF in hexadecimal. I also noticed pmap process memory map addresses max out at 0x7FFFFFFFF. But then what is the practical significance of 0x7FFFFFFFF?

The man page describes the meaning of the VmFlags:

The "VmFlags" line (available since Linux 3.8) represents
              the kernel flags associated with the virtual memory area,
              encoded using the following two-letter codes:

                     rd   -   readable
                     wr   -   writable
                     ex   -   executable
                     sh   -   shared
                     mr   -   may read
                     mw   -   may write
                     me   -   may execute
                     ms   -   may share

What is the difference between "readable" and "may read"? Those seem equivalent. Same for the write/executable/share versions.

Utilities such as ps and top are good for looking at many processes side-by-side. However, they are inconvenient for examining many fields of a single process and are not amenable to using grep. For example: $ ps -o pid,ppid,tname,bsdstart,start_time,start,bsdtime,etime,etimes,c=LIFE%,%cpu,cputime,rss,%mem,stat,class,nice=NICE,thcount,args -p $(pgrep syncthing) PID PPID TTY START START STARTED TIME ELAPSED ELAPSED LIFE% %CPU TIME RSS %MEM STAT CLS NICE THCNT COMMAND 20149 1836 ? 19:24 19:24 19:24:58 0:24 01:54:12 6852 0 0.3 00:00:24 38428 0.2 Ssl IDL - 13 /usr/bin/syncthing -no-browser -no-restart -logflags=0 There is /proc/$PID/status: $ cat /proc/$(pgrep syncthing)/status | head Name: syncthing Umask: 0022 State: S (sleeping) Tgid: 20149 Ngid: 0 Pid: 20149 PPid: 1836 TracerPid: 0 Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000 but this lacks useful fields such as: - CPU usage percentage - CPU time - Resident memory size / resident set size - Memory percentage - Out of Memory Score - Elapsed time - Nice priority - I/O priority The output I desire might look something like this: Name: syncthing Process ID: 20149 Parent process ID: 1836 Full command: /usr/bin/syncthing User: exampleuser UID: 1000 State: Sleeping (S) CPU priority: 19 (low) I/O scheduling class: 2 (best-effort) I/O priority level: 7 (low) Start date (ISO): 2020-06-15T21:21:53-04:00 Start date (UTC): Tue Jun 16 01:21:53 UTC 2020 Process age: 01:54:12 Cumulative CPU time: 00:00:24 Cumulative user CPU time: 00:00:24 Cumulative system CPU time: 00:00:24 Out of memory score: 2 Out of memory adjustment factor: 0 Number of threads: 13 Number of child processes: 0 with more fields from e.g. /proc/$PID/stat and /proc/$PID/statm. Does such a utility exist? Note: this question differs from [Detailed Per-Process Profiling](https://unix.stackexchange.com/questions/43936/detailed-per-process-profiling) because I am not looking for performance profiling or monitoring over time, but rather a snapshot of process information for the specific fields mentioned above in a particular format.

I have seen similar questions (https://unix.stackexchange.com/questions/35129/need-explanation-on-resident-set-size-virtual-size) , (https://unix.stackexchange.com/questions/164653/actual-memory-usage-of-a-process) , and understand the difference between RSS/VSZ. I've some uses of mmap'ing distinct virtual memory regions to the same underlying physical memory. In this case, /proc/pid/stat and /proc/pid/maps give RSS = VSZ = sum of all mappings. PSS sum is correct in this case, but I don't think summing up all PSS each time is a great way to report "actual" memory. Moreover, it will also include memory from libc and other libraries. Is this "actual memory" exposed by Linux? By actual memory, I mean: physical pages used/allocated by the process.

On Linux, I'm looking at /proc/1/cwd. This symlink is not readable as a normal user:

$ ls /proc/1/cwd
ls: cannot access '/proc/1/cwd': Permission denied

But /proc/1 is accessible:

$ ls /proc/1

After becoming root, you see that /proc/1/cwd points to / (filesystem root):

$ sudo ls -l /proc/1/cwd
lrwxrwxrwx 1 root root 0 Feb 21 12:56 /proc/1/cwd -> /

And of course the filesystem root is readable, as a normal user:

$ ls /

If symbolic links don't have any permissions on Linux, then why is such a symbolic link not readable, when its target (the filesystem root) is readable?