New answers tagged

1

This comment explains how programs terminate (or not) when the other end of the pipe gets closed: Closing the pipe in command1 does not tell command2 anything at all. Nothing happens until command2 reads the pipe, empties it, and gets an EOF. Even then, it does not have to exit if it has work still to do. Similarly, if command2 exits first, command1 does ...


0

Usually you should check: /etc/cron.daily/ /etc/cron.hourly/ Check crontab -e as standard user, root and as a system vnc user. Additionally check directory does it contain any file /etc/rc.d/ Check this file does it contain any entry which start with the system: /etc/rc.d/rc.local Check units here: /etc/systemd/system/ Bear in mind that if you have a ...


0

This look like you're having two monitors? One ist for DISPLAY=:1 the other for DISPLAY=:2, running on rfbports 5901 and 5902. You can try to connect to 5902 instead of 5901 to see what's there. (check for /etc/systemd/system/vncserver@:2.service) EDIT: check status of units: systemctl status vncserver@:1.service systemctl status vncserver@:2.service


-1

The shell checks for outstanding traps only at specific checkpoints (at the end of a command) and when it is implicitly waiting for a running command, it is just before such a checkpoint. On the other side: if you do not use trap .... TERM, the signal is used with default behavior which is to terminate the process (even the shell). If you use trap .... TERM, ...


0

You could use htop as well - it can show columns like RBYTES/WBYTES and IO_READ_RATE/IO_WRITE_RATE.


0

You can use iotop. One option is to use the -p option to specify the ID of the process in which you're interested. Alternatively, you can use the -u option to specify the username in which you're interested. $ sudo iotop -p 253108 Total DISK READ : 0.00 B/s | Total DISK WRITE : 593.49 M/s Actual DISK READ: 19.98 K/s | Actual DISK WRITE: ...


0

Known bug: "Memory leak in goferd on clients connected to Red Hat Satellite 6.2.x when qrouterd is unavailable".


2

The process you're seeing from ps is the grep process you're using to filter for lines containing vscode, not vscode itself. Every time you run it, you're running a new instance of grep so it gets a new pid. You can't kill that process because by the time you go to kill it, grep has already terminated. See https://unix.stackexchange.com/a/74186/90691


0

Question: "How to default each new gedit window to standalone?" Radio Controlled 17 Sept 2019 Background: gedit opens text files. The default application for opening files of type TEXT was likely set to gedit. Application gedit opens new files in a separate tab, not in a separate window. Solution: Change the default application from gedit to ...


0

Just to elaborate on the answer of Steven. awk will fail if the filenames contain spaces, instead we can use lsof to output the filename column only: lsof -Fn | grep '.pdf$' | sed s/^n// To limit the listing to a specific user, use -u username. e.g: lsof -u $(whoami) -Fn | grep '.pdf$' | uniq | sed s/^n// You can also limit the listing to a specific ...


3

stderr is just a predefined stream with file number 2 the convention is to print there important or alternative information (it does not have to be an error). For example curl will by default output the messages triggered by --verbose to stderr because stdout is already being used to get the actual result. So you will have a zero exit code and output to ...


3

Yes, programs can output to standard error and still return a zero exit status. You will find many POSIX utilities specifications which state that "The standard error shall be used only for diagnostic messages." A clear example of a program that outputs to STDERR and returns 0 is crontab. Try EDITOR=nano crontab -e 2> stderr.out; echo $? Do not ...


0

Method 2 and 3 (modifying ps, top, libraries), is prone to walk around breach. E.g. an attacker can just use there own ps. A better way would be to block these tools from accessing info on processes of other users. Then running the processes to be hidden as a different user. For the 1st part, edit /etc/fstab, to include #protect /proc proc /proc proc ...


1

The procinfo.py script does this, available in the source code of the python psutil library. It is not, however, generally packaged with psutil itself. Here is an example of its output: $ procinfo.py $(pgrep syncthing) pid 19383 name syncthing parent 1836 (syncthing) exe /usr/bin/syncthing cwd /home/nathaniel cmdline /...


0

Use the pv pipe view util: seq -w 1 1000000 | pv -lcs 1M | while read i; do (./myscript.pl $i >> output.txt); done ...which will output to STDERR a constantly updated progress bar giving both the number of lines read, and the percentage of lines done at the moment.


2

Yes, such a utility exists. I wrote one. When version 1.41 of the nosh toolkit comes out, it will be available. Fields are emitted in vis(3) encoded form, precisely so that they are machine-parseable by tools that break fields on whitespace. One can, for example, feed the output into awk and do awk's usual field matching, without (as is well-known to be the ...


5

You can use the -O option to add columns to a default selection, but it doesn’t match -f: ps -O uid,gid shows pid, uid, gid, state, tty, time and command. (The manpage mentions a “state”-less variant, which I assume is supposed to correspond to ”System V” v. “BSD” mode, but the column definitions for -O don’t support this.) If you want a specific set of ...


1

Are the pids related in some way? In this case obviously yes. Either they have a common parent process or one of the processes is the parent process of the other ones. The common file handle (4 for port 80 and 6 for port 443) is an indication that the parent process created a "socket" before starting the child processes. Can multiple processes ...


0

Are the pids related in some way? Not necessarily. They have to belong to the same effective user ID though, to prevent port hijacking. Can multiple processes listen same pid/port at the same time? Yes, with the socket option SO_REUSEPORT. This page (python example included) explains how it works and how it is related to SO_REUSEADDR (also used in servers)...


3

If the spawned process is launching other processes and then exiting, the new processes should all have the same process group ID (PGID) and that should be the PID of the original process (37977 in your example). So what you want is a way of killing all processes in a PGID. This can be done with kill and a negative PID, as explained in man kill: -n ...


1

Since you're calling a command with a different argument for each element, check what argument that command is currently processing. ps w -C myscript.pl You can get an approximate value by checking how many write system calls the seq process has performed. Find the process ID with pgrep seq (or some other command such as ps uw -C seq if there are multiple ...


0

I don't know what your script does, but could you watch cat output.txt in another terminal to monitor what your output file looks like? Alternatively (and I know this isn't what you're asking for) perhaps run your command like this: seq -w 1 1000000 | while read i; do (./myscript.pl $i >> output.txt & echo i); done or seq -w 1 1000000 | while read ...


2

Change the awk variables to root and pgrep. $ /bin/ps -eo pid,ppid,user,euser,args | awk -v user=hl -v procname=kwalletd5 '{ a[$1]=$0; }; '\ '( $3==user || $4==user ) && $5 ~ procname '\ '{ print "-------------------------"; print; print "parent process:"; print a[$2]; }' ------------------------- 4730 2725 hl hl /usr/bin/...


2

The process was expecting input from the terminal and apparently I missed any output messages in this regard. The problem was revealed after inspecting the process with strace (thanks @Hauke Laging) yielding, --- stopped by SIGTTIN --- A description of this signal is provided in gnu.org, A process cannot read from the user’s terminal while it is running ...


0

And option is to use screen: $ screen # to create the screen $ sudo apt install git ctrl-A d # to detach the screen $ screen -r # to reattach


1

What likely happens here is that the initial executable uses an exec...() system call(*) to replace all its code by a new executable and parameters and the very same process id will correspond to that new code and be listed as such by ps, so that the initial executable disappears from the process list. This is often used to set up an environment for another ...


1

It depends on the Exec line, it might be a shell script running another executable or it might be a link or even an executable spawning another. I'm not sure how you can get the information only from desktop file however one solution might be to run it... Note that I don't have google-chrome so I use chromium in my example. # Extract the command from ...


Top 50 recent answers are included