DOCSLIB.ORG

Linux Scripting Signals & Traps Signals

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux Scripting Signals & Traps Signals Linux Scripting Signals & Traps Signals • Linux supports both POSIX reliable signals and POSIX real-time signals. • A signal is a “software interrupt” • A signal interrupts a process • The process may halt • The process may “catch” the signal • Signals have no “bodies” Signals • In Linux, every signal has a name that begins with characters SIG. For example : • A SIGINT signal that is generated when a user presses ctrl+c. This is the way to terminate programs from terminal. • A SIGALRM is generated when the timer set by alarm function goes off. • A SIGABRT signal is generated when a process calls the abort function. • Etc To see the signals available on your system type: kill -l Signal Name Description SIGSTOP 19 Stop executing(can't be caught or ignored) (POSIX) SIGHUP 1 Hangup (POSIX) SIGTSTP 20 Terminal stop signal (POSIX) SIGINT 2 Terminal interrupt (ANSI) 21 Background process trYing to read, from TTY SIGQUIT 3 Terminal quit (POSIX) SIGTTIN (POSIX) SIGILL 4 Illegal instruction (ANSI) SIGTTOU 22 Background process trYing to write, to TTY (POSIX) SIGTRAP 5 Trace trap (POSIX) SIGIOT 6 IOT Trap (4.2 BSD) SIGURG 23 Urgent condition on socket (4.2 BSD) SIGBUS 7 BUS error (4.2 BSD) SIGXCPU 24 CPU limit exceeded (4.2 BSD) Floating point exception SIGFPE 8 25 (ANSI) SIGXFSZ File size limit exceeded (4.2 BSD) Kill(can't be caught or SIGVTALRM 26 Virtual alarm clock (4.2 BSD) SIGKILL 9 ignored) (POSIX) SIGPROF 27 Profiling alarm clock (4.2 BSD) User defined signal 1 SIGUSR1 10 (POSIX) SIGWINCH 28 Window size change (4.3 BSD, Sun) Invalid memory segment SIGSEGV 11 SIGIO 29 I/O now possible (4.2 BSD) access (ANSI) User defined signal 2 SIGPWR 30 Power failure restart (SYstem V) SIGUSR2 12 (POSIX) Write on a pipe with no SIGPIPE 13 reader, Broken pipe (POSIX) SIGALRM 14 Alarm clock (POSIX) To see the signals available on Your sYstem tYpe: SIGTERM 15 Termination (ANSI) kill -l SIGSTKFLT 16 Stack fault Child process has stopped SIGCHLD 17 or exited, changed (POSIX) Continue executing, if SIGCONTv 18 stopped (POSIX) Signals • When the signal occurs, the process has to tell the kernel (i.e., the OS) what to do with it. • There can be three options through which a signal can be disposed : • The signal can be ignored. Nothing will be done when signal occurs. • The signal can be caught. • Let the default action apply. Signals • three options: • The signal can be ignored. Nothing will be done when signal occurs. • Most of the signals can be ignored but signals generated by hardware exceptions like divide by zero, if ignored can have weird consequences. • A couple of signals like SIGKILL and SIGSTOP cannot be ignored. Signals • three options: • The signal can be caught. • The process must register a function with kernel. • This function is called by kernel when that signal occurs. • If the signal is non fatal for then in that function the process can handle the signal properly Signals • three options: • Let the default action apply. • Every signal has a default action. This could be process terminate, ignore etc. • The default action of SIGKILL and SIGSTOP is to terminate the process. Signals: catching • In the process code this is done by registering a function to kernel which the kernel calls when the signal occurs. • the function that the process registers must be reentrant. • what are reentrant functions? • A reentrant function is a function whose execution can be stopped in between due to any reason (like due to interrupt or signal) • and then can be reentered again safely before its previous invocations complete the execution. Signals: catching • Suppose a function func() is registered for a call back on a signal occurrence. • Now assume that this func() was already in execution when the signal occurred. • Since this function is call back for this signal so the current execution on this signal will be stopped by the scheduler • and this function will be called again (due to signal). • Assume that func() works on some global values or data structures • Could be left in inconsistent state when the execution of this function was stopped in middle • the second call to same function(due to signal) may cause some undesired results. Signals: BASH • In the absence of any traps, an interactive Bash shell ignores SIGTERM and SIGQUIT. • SIGINT is caught and handled, • if job control is active, SIGTTIN, SIGTTOU and SIGTSTP are also ignored. • Commands that are run as the result of a command substitution also ignore these signals, when keyboard generated. Signals: BASH • SIGHUP by default exits a shell. • An interactive shell will send a SIGHUP to all jobs, running or stopped; • see the documentation on the disown built-in if you want to disable this default behavior for a particular process. • Use the huponexit option for killing all jobs upon receiving a SIGHUP signal, using the shopt built-in. Bash: sending signals • Via the command line: • CTRL-C • The interrupt signal, • sends SIGINT to the job running in the foreground. • CTRL-Y • The delayed suspend character. • Causes a running process to be stopped when it attempts to read input from the terminal. • Control is returned to the shell, the user can foreground, background or kill the process. • Delayed suspend is only available on operating systems supporting this feature. • CTRL-Z • The suspend signal, sends a SIGTSTP to a running program, thus stopping it and returning control to the shell. Sending signals with kill • In Bash, both signal names and numbers are accepted as options, and arguments may be job or process IDs. • An exit status can be reported using the -l option: zero when at least one signal was successfully sent, non-zero if an error occurred. • Using the kill command from /usr/bin, your system might enable extra options, • such as the ability to kill processes from other than your own user ID • and specifying processes by name, like with pgrep and pkill. • Both kill commands send the TERM signal if none is given. Sending signals with kill Signal name Signal value Effect SIGHUP 1 Hangup SIGINT 2 Interrupt from keyboard SIGKILL 9 Kill signal SIGTERM 15 Termination signal SIGSTOP 17,19,23 Stop the process BASH: sending signals • When killing a process or series of processes, it is common sense to start trying with the least dangerous signal, SIGTERM. • programs that care about an orderly shutdown get the chance to follow the procedures that they have been designed to execute when getting the SIGTERM signal, • such as cleaning up and closing open files. • If you send a SIGKILL to a process, you remove any chance for the process to do a tidy cleanup and shutdown. traps • The trap statement allows signals to be caught • can be programmed to execute a list of commands upon catching those signals. • Syntax: trap [COMMANDS] [SIGNALS] traps • Syntax: trap [COMMANDS] [SIGNALS] • This instructs the trap command to catch the listed SIGNALS, • SIGNALS may be signal names with or without the SIG prefix, or signal numbers. • If a signal is 0 or EXIT, the COMMANDS are executed when the shell exits. • If one of the signals is DEBUG, the list of COMMANDS is executed after every simple command. • A signal may also be specified as ERR; in that case COMMANDS are executed each time a simple command (not a complex command like an if) exits with a non-zero status. traps • Syntax: trap [COMMANDS] [SIGNALS] • The return status of the trap command itself is zero unless an invalid signal specification is encountered. • The trap command takes a couple of options, which are documented in the Bash info pages. Example #!/bin/bash # traptest.sh trap "echo Booh!" SIGINT SIGTERM echo "pid is $$" while : # This is the same as "while true". do sleep 60 # This script is not really doing anything. done BASH: recieving signals • When Bash receives a signal for which a trap has been set • If the Bash is waiting for a command to complete, the trap will not be executed until the command completes. • If the Bash is waiting for an asynchronous command via the wait built-in, the reception of a signal for which a trap has been set will cause the wait built-in to return immediately with an exit status greater than 128, immediately after which the trap is executed. Example 1 • When debugging longer scripts, you might want to give a variable the trace attribute and trap DEBUG messages for that variable. • Normally you would just declare a variable using an assignment like VARIABLE=value. • To trace, replace the declaration of the variable with the declare line: declare -t VARIABLE=value # the –t option traces trap "echo VARIABLE is being used here." DEBUG # rest of the script Example 2 • The whatis command relies on a database which is regularly built using the makewhatis.cron script with cron: #!/bin/bash LOCKFILE=/var/lock/makewhatis.lock # Previous makewhatis should execute successfully: [ -f $LOCKFILE ] && exit 0 # Upon exit, remove lockfile. trap "{ rm -f $LOCKFILE ; exit 255; }" EXIT touch $LOCKFILE makewhatis -u -w exit 0 Example 3 #!/bin/sh Signal 1 is SIGUP trap cleanup 1 2 3 6 Signal 2 is SIGINT (CTRL-C) Signal 3 is SIGQUIT cleanup() Signal 6 is SIGKILL { echo "Caught Signal ... cleaning up." rm -rf /tmp/temp_*.$$ echo "Done cleanup ... quitting." Exercise: create a script that creates a new file and then exit 1 loops continuously. } When you get a SIGINT signal, remove the file and exit. ### main script for i in * do sed s/FOO/BAR/g $i > /tmp/temp_${i}.$$ && mv /tmp/temp_${i}.$$ $i done Example 4 #!/bin/sh ### main script trap 'increment' 2 X=0 while : increment() do What does this do? { echo "X=$X" echo "Caught SIGINT ..." X=`expr ${X} + 1` X=`expr ${X} + 500` sleep 1 done if [ "${X}" -gt "2000" ] then echo "Okay, I'll quit ..." exit 1 fi }.
Load more

Recommended publications
  • Systems Programming II
    Systems Programming II Iqbal Mohomed CSC 209 – Summer 2004 Week 7 Motivation for Signals • When a program forks into 2 or more processes, rarely do they execute independently of each other • The processes usually require some form of synchronization, and this is typically handled using signals. Job control is another important use • Data usually needs to be passed between processes also, and this is typically handled using pipes and sockets, which we will discuss shortly • Signals are usually generated by – Machine interrupts – The program itself, other programs, or the user (i.e. from the keyboard) Introduction to Signals • When a C program receives a signal, control is immediately passed to a function called a signal handler • The signal handler function can execute some C statements and exit in three different ways: – Return control to the place in the program which was executing when the signal occurred – Return control to some other point in the program – Terminate the program by calling the exit (or _exit) function signal() • A default action is provided for each kind of signal, such as terminate, stop or ignore • For nearly all signal types, the default action can be changed using the signal() function. The exceptions are SIGKILL and SIGSTOP. The handler is defined as follows: – typedef void (*sighandler_t)(int); • To change the handler: – sighandler_t signal(int signum, sighandler_t handler); More on signal() • For each process, the OS maintains a table of actions that should be performed for each kind of signal. The signal() function changes the table entry for the signal named as the first argument to the value provided as the second argument.
    [Show full text]
  • Unix System Programming Overview Outline What Is a Signal? Signal
    Overview Last Week: ● How to program UNIX processes (Chapters 7-9) ● fork() and exec() Unix System Programming This Week, and next week: ● UNIX inter-process communication mechanisms: signals, Signals » (next week) pipes and FIFOs. ● How to program with UNIX signals (Chapter 10) » http://en.wikipedia.org/wiki/Unix_signal ● Non-local jumps (Chapter 7) ● Focus on the sigaction() function Maria Hybinette, UGA 1 Maria Hybinette, UGA 2 Outline What is a Signal? ● A signal is an asynchronous event which is ● What is a UNIX signal? delivered to a process (instantiated by a small message) ● Signal types ● Asynchronous means that the event can occur ● Generating signals at any time (e.g., posting at a bulletin board ) ● Responding to a signal » may be unrelated to the execution of the process ● Common uses of a signal – e.g., user types Ctrl-C, or the modem hangs (SIGINT) ● Implementing a read() time-out – e.g,, user types Ctrl-Z (SIGTSTP) ● Sent from kernel (e.g. detects divide by zero ● Non-local jumps setjmp()/longjmp() (SIGFPE) or could be at the request of another ● POSIX signals process to send to another) ● Interrupted system calls ● Only information that a signal carries is its ● System calls inside handlers unique ID and that it arrived Maria Hybinette, UGA 3 Maria Hybinette, UGA 4 Signal Types (31 in POSIX) Signal Sources terminal memory ID Name Description Default Action driver management shell command 2 SIGINT Interrupt from keyboard (^C) terminate Ctr-C SIGINT SIGHUP 3 SIGQUIT Quit from keyboard (^\) terminate & core SIGSEGV 9 SIGKILL
    [Show full text]
  • POSIX Signals
    CSE 410: Systems Programming POSIX Signals Ethan Blanton Department of Computer Science and Engineering University at Buffalo Introduction Signals Blocking Concurrency Sending Signals Summary References POSIX Signals POSIX signals are another form of interprocess communication. They are also a way to create concurrency in programs. For these two reasons, they are rather complicated and subtle! Signals provide a simple message passing mechanism. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals as Messages POSIX signals are asynchronous messages. Asynchronous means that their reception can occur at any time.1 The message is the reception of the signal itself. Each signal has a number, which is a small integer. POSIX signals carry no other data. 1Almost. We’ll see how to control it later. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signal Types There are two basic types of POSIX signals: Reliable signals Real-time signals Real-time signals are much more complicated. In particular, they can carry data. We will discuss only reliable signals in this lecture. © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Asynchronous Reception From the point of view of the application: Signals can be blocked or ignored Enabled signals may be received between any two processor instructions A received signal can run a user-defined function called a signal handler This means that enabled signals and program code must very carefully manipulate shared or global data! © 2018 Ethan Blanton / CSE 410: Systems Programming Introduction Signals Blocking Concurrency Sending Signals Summary References Signals POSIX defines a number of signals by name and number.
    [Show full text]
  • Programming with POSIX Threads II
    Programming with POSIX Threads II CS 167 IV–1 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Global Variables int IOfunc( ) { extern int errno; ... if (write(fd, buffer, size) == –1) { if (errno == EIO) fprintf(stderr, "IO problems ...\n"); ... return(0); } ... } CS 167 IV–2 Copyright © 2008 Thomas W. Doeppner. All rights reserved. Unix was not designed with multithreaded programming in mind. A good example of the implications of this is the manner in which error codes for failed system calls are made available to a program: if a system call fails, it returns –1 and the error code is stored in the global variable errno. Though this is not all that bad for single-threaded programs, it is plain wrong for multithreaded programs. Coping • Fix Unix’s C/system-call interface • Make errno refer to a different location in each thread – e.g. #define errno __errno(thread_ID) CS 167 IV–3 Copyright © 2008 Thomas W. Doeppner. All rights reserved. The ideal way to solve the “errno problem” would be to redesign the C/system-call interface: system calls should return only an error code. Anything else to be returned should be returned via result parameters. (This is how things are done in Windows NT.) Unfortunately, this is not possible (it would break pretty much every Unix program in existence). So we are stuck with errno. What can we do to make errno coexist with multithreaded programming? What would help would be to arrange, somehow, that each thread has its own private copy of errno. I.e., whenever a thread refers to errno, it refers to a different location from any other thread when it refers to errno.
    [Show full text]
  • POSIX Signal Handling in Java
    Technical Document Series POSIX Signal Handling in Java POSIX Signal Handling In Java Introduction POSIX signals inform a running process of external events, such as the user wishing to kill the process, or the operating system signaling an impending shutdown, or the process being suspended or reinstated; or the process may have violated a resource constraint, such as excessive CPU usage or attempts to access areas outside its permitted memory space, and is asked to shutdown. In short, POSIX signals serve many different purposes. Some are even up to interpretation, such as the HUP (HangUP) signal, which is commonly used to inform a process that something about its environment has changed and the process should adjust accordingly. Some programs may interpret this to mean that the configuration has changed and needs to be reloaded; or the log file has been moved for archiving purposes and a new one should be started. The use of signals is widespread, especially on Unix-based operating systems, but Java provides no standard interface for a Java application to hear and react to them. This document shows you how to get around this limitation. The Good, the Bad, and the Ugly The good news is that there is a way to intercept POSIX signals and react to them in Java. This would allow your Java program to avoid being killable with ^C (SIGINT), for example, even ignore termination requests from the operating system (SIGTERM). Neither of these is necessarily a good idea, of course, unless you know exactly why you would want to catch these signals and either handle them yourself or ignore them altogether.
    [Show full text]
  • Processes and Job Control
    Processes and Job Control Hour 17 PObjectives < Definitions: process, orphan, and zombie < System processes < Process creation < Examining processes: the ps command < Job control: &, nohup, fg, bg, jobs, ( ), and kill < Exit status Copyright © 1998-2002 Delroy A. Brinkerhoff. All Rights Reserved. Hour 17 Unix Slide 1 of 12 Process Also called a job by C and Korn shells PWhen a program or executable file is loaded from disk and started running (i.e., when a command is run), it is called a process vi pid 641 < identified by a unique process ID (PID) number < has an owner vi < private data vi PA program can be loaded more than once pid 895 < creates multiple processes vi < each process has a different PID < each process may have a different owner PPIDs are unique, nonnegative integers < numbers recycle without collisions Hour 17 Unix Slide 2 of 12 System Processes Processes created during system boot P0System kernel < “hand crafted” at boot < called swap in older versions (swaps the CPU between processes) < called sched in newer versions (schedules processes) < creates process 1 P1 init (the parent of all processes except process 0) < general process spawner < begins building locale-related environment < sets or changes the system run-level P2 page daemon (pageout on most systems) P3 file system flusher (fsflush) Hour 17 Unix Slide 3 of 12 Process Life Cycle Overview of creating new processes fork init init pid 467 Pfork creates two identical pid 1 exec processes (parent and child) getty pid 467 Pexec < replaces the process’s instructions
    [Show full text]
  • Site Map - Apache HTTP Server 2.0
    Site Map - Apache HTTP Server 2.0 Apache HTTP Server Version 2.0 Site Map ● Apache HTTP Server Version 2.0 Documentation ❍ Release Notes ■ Upgrading to 2.0 from 1.3 ■ New features with Apache 2.0 ❍ Using the Apache HTTP Server ■ Compiling and Installing Apache ■ Starting Apache ■ Stopping and Restarting the Server ■ Configuration Files ■ How Directory, Location and Files sections work ■ Server-Wide Configuration ■ Log Files ■ Mapping URLs to Filesystem Locations ■ Security Tips ■ Dynamic Shared Object (DSO) support ■ Content Negotiation ■ Custom error responses ■ Setting which addresses and ports Apache uses ■ Multi-Processing Modules (MPMs) ■ Environment Variables in Apache ■ Apache's Handler Use ■ Filters ■ suEXEC Support ■ Performance Hintes ■ URL Rewriting Guide ❍ Apache Virtual Host documentation ■ Name-based Virtual Hosts ■ IP-based Virtual Host Support ■ Dynamically configured mass virtual hosting ■ VirtualHost Examples ■ An In-Depth Discussion of Virtual Host Matching ■ File descriptor limitations ■ Issues Regarding DNS and Apache ❍ Apache Server Frequently Asked Questions http://httpd.apache.org/docs-2.0/sitemap.html (1 of 4) [5/03/2002 9:53:06 PM] Site Map - Apache HTTP Server 2.0 ■ Support ❍ Apache SSL/TLS Encryption ■ SSL/TLS Encryption: An Introduction ■ SSL/TLS Encryption: Compatibility ■ SSL/TLS Encryption: How-To ■ SSL/TLS Encryption: FAQ ■ SSL/TLS Encryption: Glossary ❍ Guides, Tutorials, and HowTos ■ Authentication ■ Apache Tutorial: Dynamic Content with CGI ■ Apache Tutorial: Introduction to Server Side Includes ■ Apache
    [Show full text]
  • System Calls & Signals
    CS345 OPERATING SYSTEMS System calls & Signals Panagiotis Papadopoulos [email protected] 1 SYSTEM CALL When a program invokes a system call, it is interrupted and the system switches to Kernel space. The Kernel then saves the process execution context (so that it can resume the program later) and determines what is being requested. The Kernel carefully checks that the request is valid and that the process invoking the system call has enough privilege. For instance some system calls can only be called by a user with superuser privilege (often referred to as root). If everything is good, the Kernel processes the request in Kernel Mode and can access the device drivers in charge of controlling the hardware (e.g. reading a character inputted from the keyboard). The Kernel can read and modify the data of the calling process as it has access to memory in User Space (e.g. it can copy the keyboard character into a buffer that the calling process has access to) When the Kernel is done processing the request, it restores the process execution context that was saved when the system call was invoked, and control returns to the calling program which continues executing. 2 SYSTEM CALLS FORK() 3 THE FORK() SYSTEM CALL (1/2) • A process calling fork()spawns a child process. • The child is almost an identical clone of the parent: • Program Text (segment .text) • Stack (ss) • PCB (eg. registers) • Data (segment .data) #include <sys/types.h> #include <unistd.h> pid_t fork(void); 4 THE FORK() SYSTEM CALL (2/2) • The fork()is one of the those system calls, which is called once, but returns twice! Consider a piece of program • After fork()both the parent and the child are ..
    [Show full text]
  • NSWI 0138: Advanced Unix Programming
    NSWI 0138: Advanced Unix programming (c) 2011-2016 Vladim´ırKotal (c) 2009-2010 Jan Pechanec, Vladim´ırKotal SISAL MFF UK, Malostransk´en´am.25, 118 00 Praha 1 Charles University Czech Republic Vladim´ırKotal [email protected] March 10, 2016 1 Vladim´ırKotal NSWI 0138 (Advanced Unix programming) Contents 1 Overview 5 1.1 What is this lecture about? . .5 1.2 The lecture will cover... .5 1.3 A few notes on source code files . .6 2 Testing 6 2.1 Why?...........................................6 2.2 When ? . .6 2.3 Types of testing . .7 3 Debugging 8 3.1 Debuging in general . .8 3.2 Observing . .9 3.3 Helper tools . .9 3.3.1 ctags . .9 3.3.2 cscope . 10 3.3.3 OpenGrok . 11 3.3.4 Other tools . 11 3.4 Debugging data . 11 3.4.1 stabs . 11 3.4.2 DWARF . 12 3.4.3 CTF (Compact C Type Format) . 12 3.5 Resource leaks . 13 3.6 libumem . 13 3.6.1 How does libumem work . 14 3.6.2 Using libumem+mdb to find memory leaks . 14 3.6.3 How does ::findleaks work . 16 3.7 watchmalloc . 17 3.8 Call tracing . 18 3.9 Using /proc . 19 3.10 Debugging dynamic libraries . 20 3.11 Debuggers . 20 3.12 Symbol search and interposition . 20 3.13 dtrace . 21 4 Terminals 21 4.1 Terminal I/O Overview . 21 4.2 Terminal I/O Overview (cont.) . 22 4.3 Physical (Hardware) Terminal . 24 4.4 stty(1) command . 24 4.5 TTY Driver Connected To a Phy Terminal .
    [Show full text]
  • Processes in Linux/Unix
    Processes in Linux/Unix A program/command when executed, a special instance is provided by the system to the process. This instance consists of all the services/resources that may be utilized by the process under execution. • Whenever a command is issued in unix/linux, it creates/starts a new process. For example, pwd when issued which is used to list the current directory location the user is in, a process starts. • Through a 5 digit ID number unix/linux keeps account of the processes, this number is call process id or pid. Each process in the system has a unique pid. • Used up pid’s can be used in again for a newer process since all the possible combinations are used. • At any point of time, no two processes with the same pid exist in the system because it is the pid that Unix uses to track each process. Initializing a process A process can be run in two ways: 1. Foreground Process : Every process when started runs in foreground by default, receives input from the keyboard and sends output to the screen. When issuing pwd command $ ls pwd Output: $ /home/geeksforgeeks/root When a command/process is running in the foreground and is taking a lot of time, no other processes can be run or started because the prompt would not be available until the program finishes processing and comes out. 2. Backround Process : It runs in the background without keyboard input and waits till keyboard input is required. Thus, other processes can be done in parallel with the process running in background since they do not have to wait for the previous process to be completed.
    [Show full text]
  • Intro to Unix 2018
    Introduction to *nix Bill Renaud, OLCF ORNL is managed by UT-Battelle for the US Department of Energy Background • UNIX operating system was developed in 1969 by Ken Thompson and Dennis Ritchie • Many “UNIX-like” OSes developed over the years • UNIX® is now a trademark of The Open Group, which maintains the Single UNIX Specification • Linux developed by Linus Torvalds in 1991 • GNU Project started by Richard Stallman in 1983 w/aim to provide free, UNIX-compatible OS • Many of the world’s most powerful computers use Linux kernel + software from the GNU Project References: 1www.opengroup.org/unix 2https://en.wikipedia.org/wiki/Linux 2 3https://www.gnu.org/gnu/about-gnu.html This Presentation • This presentation will focus on using *nix operating systems as a non-privileged user in an HPC environment – Assumes you’re using a ‘remote’ system – No info on printing, mounting disks, etc. • We’ll focus on systems using the Linux kernel + system software from the GNU project since that’s so prevalent • Two-Part – Basics: general information, commands – Advanced: advanced commands, putting it all together, scripts, etc. 3 This Presentation • May seem a bit disjoint at first – Several basic concepts that don’t flow naturally but later topics build upon – Hopefully everything will come together, but if not… • I’ll cover (what I hope is) some useful info but can’t cover it all – People write thousand-page books on this, after all • Please ask questions! 4 Basics Terminology • User – An entity that interacts with the computer. Typically a person but could also be for an automated task.
    [Show full text]
  • CST8207 – Linux O/Si
    Processes 1 elinks, mail processes nice ps, pstree, top job control, jobs, fg, bg signals, kill, killall crontab, anacron, at 2 elinks is a text-based (character mode) web browser we will use it to enable our scripts to retrieve web pages in assignment 6, we use it to retrieve a weather webpage elinks -dump -no-numbering -no-references <URL> Example elinks -dump -no-numbering -no-references \ 'http://weather.gc.ca/rss/city/on-118_e.xml' Could grep this to extract information (maybe with –A option) 3 use the mail command to send outgoing and read incoming email on the CLS Sending outgoing email (bold font shows what the user types) $ mail [email protected] Cc: Subject: First Message from CLS This is a test message. ^D $ 4 text mode mail reader incoming email is stored in /var/spool/mail/<username> use the mail command to read it you'll see a list of messages, each preceded by a number (the header list) enter a number to see that message enter h to see the header list again when you enter q, mail will quit and messages you read will be stored in ~/mbox mail –f to see the messages in ~/mbox 5 Any program we run executes as a process Processes have the following attributes ◦ a process id: PID ◦ a parent process id: PPID ◦ a nice number (related to priority) ◦ controlling terminal ◦ Real (RUID) and effective (EUID) user id ◦ Real (RGID) and effective (EGID) group id Also: ◦ a current working directory ◦ a umask value ◦ an environment (values of environment variables) 6 We have already been using the ps command
    [Show full text]