How do I log all input and output in a terminal session?
How do I keep logs of all the work done via terminal? For example, I want a record of all the work done on database via terminal.
4 Answers 4
When you are ready to start recording a log file, type:
Now, until you stop the script, all input and output in the Terminal will be stored in screen.log. When you are done, just type:
Your screen.log file will stored in the local directory. If you want to redirect it, use an absolute pathname such as ~/screen.log . This will do exactly what you are looking for.
Hi, thanks for the reply. But will this work if I login to the mysql database from the shell using the following sequence:- 1) script screen.log 2)mysql -u
it should work with everything running in the console reading from «standard input» (usually your keyboard) and writing to standard output (usually your terminal window). So it should include the mysql command-line client. The man page ( man script ) even mentions vi (editor).
You may want to try out Asciinema. In addition to just making a recording you get the ability to share it and embed the player on your blog, article or in a conference talk.
I have a better way to use syslog for logging every shell command this can be vary upon linux distribution but method will remain same
You need to follow some steps:
Step # 1 (Create Syslog service)
# vim /etc/rsyslog.d/bash.conf local6.* /var/log/commands.log Step # 2 (Open bashrc and enter below command)
# vim /root/.bashrc # Enable CLI Logging by Mansur 08-12-2016 whoami="$(whoami)@$(echo $SSH_CONNECTION | awk '')"export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$whoami [$$]: $(history 1 | sed "s/^[ ]*8\+[ ]*//" ) [$RETRN_VAL]"' Ste # 3 (Restart Syslog Service)
Dec 7 22:13:00 validationdb2 mahasan: root@export [13291]: tail -f /var/log/mysql/mysql.log [0] Dec 7 22:13:09 validationdb2 mahasan: root@export [13291]: ls -lh [0] Dec 7 22:13:27 validationdb2 mahasan: root@export [13291]: touch test command [0]
How do I log all commands executed by all users
but here it is saving only the commands executed by the root user.
I have tried using audit rules as well, but the above solutions are more accurate regarding my use case.
Audit Rules save the logs in different lines with different types: SYSCALL (user info), EXECVE (executed command args), etc. Instead, I need this information in one log line.
I have followed these steps:
# Enable CLI Logging whoami="$(whoami)@$(echo $SSH_CONNECTION | awk '')"export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$whoami [$$] $(history 1 | sed "s/^[ ]*5\+[ ]*//" )"' sudo service rsyslog restart With the above, the logs are saved in /var/log/commands.log in the following format:
Aug 13 10:10:31 ip-172-31-3-192 ec2-user: root [19399] cat /var/log/commands.log and the commands are saved only if I use sudo su (root). If I exit from sudo su and execute any command, then the commands don’t get saved in /var/log/commands.log .
Possibly relevant — Log which system executables have been used — but does not capture the command arguments, just the command itself
The most effective and unavoidable solution uses the kernel to record the commands. Auditd, for example
1 Answer 1
Thank You Bob and https://askubuntu.com/questions/93566/how-to-log-all-bash-commands-by-all-users-on-a-server/93570#93570, I’m posting the steps that I followed from the above solution in my case (I am using Amazon Linux):
export PROMPT_COMMAND='RETRN_VAL=$?;logger -p local6.debug "$(whoami) [$$]: $(history 1 | sed "s/^[ ]*7\+[ ]*//" )"' sudo -e /etc/rsyslog.d/bash.conf sudo -e /etc/logrotate.d/syslog sudo service rsyslog restart The result will be similar to the following, where you can see commands executed by root and the other user as well:
Aug 13 13:39:02 ip-172-31-3-192 ec2-user: root [23275]: rm logrotate.d/rsyslog [0] Aug 13 13:39:08 ip-172-31-3-192 ec2-user: root [23275]: cat logrotate.d/rsyslog [1] Aug 13 13:39:23 ip-172-31-3-192 ec2-user: root [23275]: sudo cat /var/log/commands.log [0] Aug 13 13:39:27 ip-172-31-3-192 ec2-user: root [23275]: sudo cat /var/log/commands.log [0] Aug 13 13:46:22 ip-172-31-3-192 ec2-user: ec2-user [17012]: sudo su [0] Aug 13 13:46:54 ip-172-31-3-192 ec2-user: ec2-user [17012]: sudo /etc/rsyslog.d/bash.conf [1] Aug 13 13:47:00 ip-172-31-3-192 ec2-user: ec2-user [17012]: sudo cat /etc/rsyslog.d/bash.conf [0] Aug 13 13:47:10 ip-172-31-3-192 ec2-user: ec2-user [17012]: cat /etc/rsyslog.d/bash.conf [0] Logging terminal commands
Assuming you’re doing this for security purposes, take a look at process accounting. You didn’t say which UNIX variant you’re on, but for Linux, take a look at http://www.gnu.org/software/acct/ Beware that you will generate a lot of data as process accounting writes data about every command run system wide (its a kernel feature). Your distro probably has the utilities already; in Debian check the ‘acct’ package.
If you’re just trying to log what you did so you can go back and look at it later, script (as in the other answer) or screen (with -L) will provide a better solution. However, they will not work for security auditing because its trivial to bypass them: just run a shell script. Also, line editing makes a royal mess of the files. Curses apps (like, say, a text editor) are even worse.
Also, if you force your users through e.g., script, you may wind up capturing information (e.g., email messages) which it may be illegal for you to intercept.
One more option — sudosh or other equivalents. Not sure that they provide much benefit compared to script, but probably worthy of mention.
Process accounting is the way to go, despite it sucking up lots of disk space. It’s not something I’d leave running unless you have a very grunty box but it’s very useful for problem solving since it basically tracks every process, a claim the simpler «snapshot of ps» tools can’t match.
You basically turn it on with accton /var/account/pacct and the kernel then writes details of every process that exits, including:
- process name (not args, unfortunately).
- start time.
- elapsed time.
- user and system CPU times.
- exit code.
- memory, I/O, fault and swap statistics.
- process ID.
- parent process ID.
You shut it down with a naked accton so all you people who laughed at Windows for using a Start button to shut down, HAH !! 🙂
There are two variants of records that can be logged, v1 and v3 — make sure you’re using the latest process accounting software and v3 records as they hold more useful information. The /usr/include/linux/acct.h file shows what you can get from there.
The records are all fixed size (regardless of version) and easy to process.
We’ve just recently finished a Linux agent for our performance monitoring software — I thought I’d jot this down while it’s still fresh in my memory.
One thing to watch out for are the comp_t fields — these are actually a weird exponent/mantissa type for holding a large range of values in 16 bits — the algorithm is pretty simple for turning it into a long:
Another thing is that some values are in clock ticks, not seconds, so you have to divide by the value returned by sysconf (_SC_CLK_TCK) .
Is there an easy way to log all commands executed, including command line arguments?
I am trying to find how to log a specific instantiation of rrdtool to see whether the path it is receiving is incorrect. I know I could wrap the executable in a shell script that would log the parameters, but I was wondering if there was a more kernel-specific way to monitor for that, perhaps a filesystem callback that sees when a particular /proc/pid/exe matches a given binary?
Is there a way to get auditd to record the command-line arguments as well as the program ran? serverfault.com/questions/765179/…
3 Answers 3
Yes, there is a kernel facility: the audit subsystem. The auditd daemon does the logging, and the command auditctl sets up the logging rules. You can log all calls to a specific system alls, with some filtering. If you want to log all commands executed and their arguments, log the execve system call:
auditctl -a exit,always -S execve To specifically trace the invocation of a specific program, add a filter on the program executable:
auditctl -a exit,always -S execve -F path=/usr/bin/rrdtool The logs show up in /var/log/audit.log , or wherever your distribution puts them. You need to be root to control the audit subsystem.
Once you’re done investigating, use the same command line with -d instead of -a to delete a logging rule, or run auditctl -D to delete all audit rules.
For debugging purposes, replacing the program by a wrapper script gives you more flexibility to log things like the environment, information about the parent process, etc.
@Graeme The problem described in the question was tracking an invocation of rrdtool . If you want to log invocations of all programs, drop the -F path=… part (you’ll get a lot of logs of course).
This is all great, but how do I reset the config it to initial state? Otherwise it’ll continue filling the log with new and new launched commands. or is this auditctl command only effective until reboot?
@Ruslan The effect of auditctl only survives until reboot, but that’s a good point anyway, I’ve added instructions on removing them without rebooting to my answer.
Snoopy is more lightweight solution as it does not need kernel cooperation. All that is needed is dynamic loader (dl) that preloads snoopy library, path to which is specified in /etc/ld.so.preload .
Disclosure: I am current snoopy maintainer.
Is it possible to do logging for commands directly or indirectly spawned from a particular shell only?
I am not sure I understand your question — do you mean «shell» as specific program that is used as shell (bash, dash, zsh etc.), or you mean you would like to log just specific PTY? Snoopy provides filtering framework, but currently only a couple of very basic filters are implemented, see here for the list: link. If you have a concrete usecase that might be applicable to others, please do explain in feature request, and, oh, btw, patches are welcome 🙂
There is no specific filter for PTY available ATM. However, you could use snoopy to log everything, including which PTY the event occured on, and then do the filtering in your syslog daemon. I do not know which one you are using, but syslog-ng (for example) can do regex matching, positive or negative.
Sure, thanks! The tool and the approach is in general quite useful. I can easily do some filtering to get what I need.
The Linux kernel «audit» subsystem can do what you need.
e.g. if you run these commands:
auditctl -a exit,always -F arch=b64 -S execve auditctl -a exit,always -F arch=b32 -S execve Then every execution event is logged, and a lot of information is provided around that
e.g. this is the output of me running tail /var/log/audit/audit.log
exit=0 a0=7f0e4a21e987 a1=7f0e4a21e6b0 a2=7f0e4a21e808 a3=8 items=2 ppid=906 pid=928 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="tail" exe="/usr/bin/tail" subj=kernel key=(null) type=EXECVE msg=audit(1543671660.203:64): argc=2 a0="tail" a1="/var/log/audit/audit.log" type=CWD msg=audit(1543671660.203:64): cwd="/home/sweh" type=PATH msg=audit(1543671660.203:64): item=0 name="/usr/bin/tail" inode=266003 dev=fd:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=unlabeled objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PATH msg=audit(1543671660.203:64): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=273793 dev=fd:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=unlabeled objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1543671660.203:64): proctitle=7461696C002F7661722F6C6F672F61756469742F61756469742E6C6F67 There’s some interesting values that can be seen; e.g. «auid» is 500, which is my login ID, even though «uid» is zero (‘cos I’m running under su ). So even though the user may have switched accounts with su or sudo we can still track back to their «audit ID»
Now those auditctl commands will be lost on a reboot. You can put them into a configuration file (eg in the /etc/audit/rules.d/ directory, on CentOS 7). The exact location will depend on your OS version. The auditctl manual page should help here.
Beware, though. this will cause a lot of log messages to be generated. Make sure you have enough space on the disk!
If necessary the rules can be limited to a specific user, or a specific command.
And also beware; if a user puts the password in the command execution (e.g. mysql —user=username —password=passwd ) then this will be logged.