I have a question about ulimit:
ulimit -u unlimited
ulimit -n 60000
If I execute these in a screen, will they forever be kept as a setting on the screen until I kill the screen or do I have to run it every time I run the program?
What I want to do is irrelevant, I just want to know if they will be kept as a setting within the screen.
ulimit is a bash builtin. It invokes the setrlimit(2) system call.
That syscall modifies some limit in its -shell- process (likewise the cd builtin calls chdir(2) and modifies the working directory of your shell process).
In a bash shell, $$ expands to the pid of that shell process. So you can use ps $$ (and even compose it, e.g. like in touch /tmp/foo$$ or cat /proc/$$/status)
So the ulimit applies to your shell and stay the same until you do another ulimit command (or until your shell terminates).
The limits of your shell process (and also its working directory) are inherited by every process started by fork(2) from your shell. These processes include those running your commands in that same shell. Notice that changing the limit (or the working directory) of some process don't affect those of the parent process. Notice that execve(2) don't change limits or working directories.
Limits (and working directory) are properties of processes (not of terminals, screens, windows, etc...). Each process has its own : limits and working directory, virtual address space, file descriptor table, etc... You could use proc(5) to query them (try in some shell to run cat /proc/self/limits and cat /proc/$$/maps and ls -l /proc/self/cwd /proc/self/fd/). See also this. Limits (and working directory) are inherited by child process started with fork(2) which has its own copy of them (so limits are not shared, but copied ... by fork).
But if you start another terminal window, it is running another shell process (which has its own limits and working directory).
See also credentials(7). Be sure to understand how fork(2) and execve(2) work, and how your shell uses them (for every command starting a new process, practically most of them).
You mention kill(1) in some comments. Be sure to read its man page (and every man page mentioned here!). Read also kill(2) and signal(7).
A program can call by itself setrlimit(2) (or chdir(2)) but that won't affect the limits (or working directory) of its parent process (often your shell). Of course it would affect future fork-ed child processes of the process running that program.
I recommend reading ALP (a freely downloadable book about Linux programming) which has several chapters explaining all that. You need several books to explain the details.
After ALP, read intro(2), be aware of existing syscalls(2), play with strace(1) and your own programs (writing a small shell is very instructive; or study the code of some existing one), and read perhaps Operating Systems: Three Easy pieces.
NB. The screen(1) utility manages several terminals, each having typically its shell process. I don't know if you refer to that utility. Read also about terminal emulators, and the tty demystified page.
The only way to really kill some screen is with a hammer, like this:
(image of a real hammer hitting a laptop found with Google, then cut with gimp, and put temporarily on my web server; the original URL is probably https://www.istockphoto.com/fr/photo/femme-daffaires-stress%C3%A9-%C3%A0-lordinateur-crash-arrive-et-d%C3%A9truisent-le-moniteur-gm172788693-5836585 and I understand the license permits me to do that.)
Don't do that, you'll be sorry.
Apparently, you are talking of sending a signal (with kill(1) or killall(1) or pkill(1) to some process running the screen(1) program, or to its process group. It is not the same.
Related
Is there a way in linux, to determine how a process was invoked?
I know, that ps displays the startup parameters, but I'm interested how the process start was executed.
Was it a init.d script, a cron job or manual invocation via cli.
Right now I am looking through all configs/commands manually, is there an easy way I am overlooking?
(I also know, that the presence of systemd etc. is distro related which helps to priorize a little bit.)
In most cases, for a process of pid 1234, you can get valuable information about it thru /proc/1234/ (see proc(5) for details)
See also credentials(7) and Advanced Linux Programming and Linux From Scratch
For exemple, try ps $$ then cat /proc/$$/status then cat /proc/$$/maps then cat /proc/$$/comm in your terminal (running probably the GNU bash shell, or zsh)
Consider writing your C program doing appropriate syscalls(2) (with perhaps opendir(3) and readdir(3)...) to query that information from /proc/ ....
Remember to read errno(3). A lot of functions (like open(2), read(2), getpwnam(3) ....) can fail.
Download, then study for inspiration the source code of the GNU bash shell (or even of the Linux kernel), it is free software.
for my Computing Controlled Assessment I am looking into some of the basic commands for the Linux OS Debian. For the final question I have to write a short essay on using the top command along with ps and kill to investigate misbehaving system. The question asks to use help from PC specialists (or just any experienced Debian users). So if anyone could give any information on how a specialist could use these commands and anything helpful in general on these commands. Remember I'm here for information and not an answer. Thanks
top is used for displaying a list of processes, and by default, is sorted by the amount of CPU usage it's using - so in your case, it's a handy tool to see if a specific process is taking up most of the CPU usage and causing the system to run slower. It also displays the process ID (PID) as well as the user running it. Think of it like the Linux equivalent of Task Manager in Windows.
ps is similar to top, but instead of constantly refreshing, it spews out all of the current processes running on the server, as well as the PID (important). Usually this is used as ps aux, or to be more specfic you could use this with grep to search for a specific process, e.g. ps aux | grep httpd to display the current Apache processes running.
kill is used to kill process running on the system, so if you had a script on the system taking up most of the resources and you want to forcefully kill the process, you'd use kill. You can also use the killall command to kill all processes with a matching string, e.g. killall httpd.
The steps I'd take to investigate a misbehaving system would be to:
1) Use top or ps to locate the process taking up the most resources, and remember the process ID.
2) If I wanted to kill the process, I'd use: kill <process ID>.
If you need anything else clarifying or explaining - feel free to comment!
EDIT: https://serverfault.com/ - This may be the best place to post future questions like this.
Best way to learn about this commands is to read man (manual) pages. To discover information about top just type:
$ man top
in command line and enjoy. Similarly you can display man pages for most unit command line tools using:
$ man <command>
I have a process running on Slackware 13.37 that outputs data to its terminal window. Is it possible to read/redirect this output to ssh window/PuTTY without terminating/restarting the process?
You can capture the output using shell redirection or via a program such as script -- provided that your program was started "in the usual way". (It is possible to write via special devices to other terminals, given appropriate permissions).
One assumes that you already know about redirecting output, e.g.,
foo >bar
but have some case, e.g., a GUI program which continues to write to the terminal.
Without worrying about interfering with a program by redirecting its output, I would run script and start the program within the shell that script starts. Then anything written from that shell would go to the typescript file (by default).
On the other hand, GUI programs which start a terminal window may/may not be configurable to allow customizing them with a startup script that can capture output.
As noted in How to open process again in linux terminal?, it is possible to attach to a running process with strace, given its process-ID. Using the -e option as described in 7 Strace Examples to Debug the Execution of a Program in Linux, you could just extract write calls.
Keep in mind with strace that nonprinting characters from the writes are converted to printable text, and that strace displays function arguments up to a fixed limit (which you can adjust using the -s option). The output of strace can be redirected (and it need not be run on the same terminal as the original process).
I want to kill all programs running in the same directory as I do.
I need to find which programs are running right now and kill them (and to be careful to not kill myself).
I am running my program in Ubuntu(Linux).
I need to use this command:
int kill(pid_t pid, int sig);
How I can do it?
*The programs live in the same directory .
Stricto sensu, your question does not make sense. By the time you are getting the directory of a process, it could have called chdir(2) before you kill it (and then you should not have killed it).
On Linux, to get information about processes, use proc(5). So use readdir(3) after opendir(3) on /proc/ (filter only the numerical directories, like /proc/1234/ which corresponds to process of pid 1234). For each process there, use readlink(2) on /proc/1234/cwd to get its directory (and on /proc/1234/exe to get its executable, if it matters). Use getcwd(2) and getpid(2) to get current directory and current process.
BTW, your kill(2) is a syscall (listed in syscalls(2)), not a command. The command is kill(1) to be usually run from a shell.
You should read Advanced Linux Programming.
At last, your desired behavior to kill every process running in your directory is extremely user unfriendly. So at least document it, and perhaps give some way to disable that behavior. A more gentle way would be to make some temporary directory (using mkdtemp(3)) then chdir(2) into it (then perhaps unlink(2) or rmdir(2) it).
See also pkill(1) and pgrep
If I run some command-line application in Linux, how to tell which files were accessed (read and/or written) by that process? I imagine I would need to place some hooks in the file-system driver and recompile the kernel, or something like that? Is there an easier way?
strace is a command will display each system call the application makes.
From the man page:
In the simplest case strace runs the specified command until it exits. It intercepts and records the system calls which are called by a process and the signals which are received by a process. The name of each system call, its arguments and its return value are printed on standard error or to the file specified with the -o option.
For instance, each open(), read() and write() operation will show the arguments and the return code.
You can get list of file access by your application by lsof command in linux Here is list of example
In addition of other answers mentionning lsof, strace (maybe ltrace could be useful too!), fs_usage you could use for process 1234 the directory /proc/1234/, in particular the opened file descriptors are available from /proc/1234/fd/; from inside your program you could use /proc/self/fd/. See proc(5)
Perhaps inotify(7) or ptrace(2) is relevant too.