I haven’t shared this on Unix Tutorial before, but I’m a huge fan of mindmaps. I create and use them all the time for any process or knowledge that I am working with.
It seems to me that all the Unix Reference pages I’m creating will greatly benefit from mindmaps, so here’s an example of what I mean:
SSH Reference Mindmap
Why I Like Midmaps
it’s a great way to mentally place certain peices of knowledge to where they belong – so that you understand how certain topics relate to each other and this means you’ll remember them better
a mindmap is an awesome and very quick way to refresh your knowledge about something – even without specifics like port numbers and command lines you can still learn, remember and recall a lot
a mindmap is invaluable to highlighting gaps in knowledge – as you place broad topics into the midmap branch, you often realise that you need to learn more before that section is complete
it’s a great learning tool – I can just add questions about things I don’t know and come back later to update them with newly learned pieces of information
Let me know what you think!
pS: I’m preparing my Unix Tutorial Patreon page this month – so check it out and let me know how I can make Unix Tutorial better to help you learn and succeed. It will mean a lot if you decide to become a patron!
As you know, Unix filesystems store a number of timestamps for each file. This means that you can use these timestamps to find out when any file or directory was last accessed (read from or written to), changed (file access permissions were changed) or modified (written to).
File and directory timestamps in Unix
Three times tracked for each file in Unix are these:
access time atime
change time – ctime
modify time – mtime
INTERESTING: there’s no file creation timestamp kept in most filesystems – meaning you can’t run a command like “show me all files created on certain date”. This said, it’s usually possible to deduce the same from ctime and mtime (if they match – this probably means that’s when the file was created).
atime – Last Access Time
Access time shows the last time the data from a file or directory was accessed – read by one of the Unix processes directly or through commands and scripts.
Due to its definition, atime attribute must be updated – meaning written to a disk – every time a Unix file is accessed, even if it was just a read operation. Under extreme loads, atime requirement could severely impact the filesystem performance, especfially with hard disks (HDDs) compared to Solid State Disks (SSDs).
Modern Unix and Unix like operating systems have special mount options to optimise atime usage (or disable it completely).
For instance, in Linux kernel the following atime optimisations are supported when mounting filesystem:
strictatime – always update atime (no longer the default!)
relatime (“relative atime”) – selective atime updates, usually if previous atime is an older timestamp than ctime and mtime (see below)
nodiratime – no access time updates for directories (files still get atime updates)
noatime – no access time updates for anything
ctime – Last Change Time
ctime shows when your file or directory got metadata changes – typically that’s file ownership (username and/or group) and access permissions. ctime will also get updated if the file contents got changed.
mtime – Last Modification Time
Last modification time shows time of the last change to file’s contents. It does not change with owner or permission changes, and is therefore used for tracking the actual changes to data of the file itself.
INTERESTING: When a new file or directory is created, usually all three times – atime, ctime and mtime – are configured to capture the current time.
How to Use atime, ctime and mtime
Lots of common system administration tasks can be helped, if not completed, using knowledge of atime, ctime and mtime attributed:
find files updated on a certain date
confirm when was the last time a configuration file was changed
find files modified in the last hour or day – very useful for finding most recently updated log files
verify if a certain file was accessed and when – useful when debugging a script
quickly get the list of really old files (not updated for longer than 30 days or something like that)
confirm when the directory was updated – can suggest that temporary files were created and quickly deleted, so you don’t see the files but recognise evidence when they were still in the directory
review a list of files to confirm when they had ownership (user/group) data updated and if this time is different from file modifications – could be useful when reviewing security breach on your Unix system
Find atime, ctime and mtime with ls
The simplest way to confirm the times associated with a file is to use ls command. Timestamps are shown when using the long-format output of ls command, ls -l:
** ls -l**, which shows you the time of the last file modification – mtime. In our example, file /tmp/file1 was last changed around 7:10am. If we want to see the last access time for this file, atime – you need to use -lu options for ls. The output will probably show some later time:
To show you how this works, I’ll change the ownership of the file and then run the same 3 ls commands to show you that only the
ctime had been updated. I run the date command just before doing anything else so that you can compare the times:
ubuntu# date Sat Apr 5 07:35:16 IST 2008 ubuntu# chown root /tmp/file1 ubuntu# ls -lc /tmp/file1 -rw-r--r-- 1 root root 9 2008-04-05 07:35 /tmp/file1 ubuntu# ls -lu /tmp/file1 -rw-r--r-- 1 root root 9 2008-04-05 07:27 /tmp/file1 ubuntu# ls -l /tmp/file1 -rw-r--r-- 1 root root 9 2008-04-05 07:10 /tmp/file1
Show atime, ctime and mtime with stat command
In Linux distributions, you will probably find a stat command, which can be used to show all of the times in a more convenient way, and among plenty of other useful information about your file:
I’ve noticed how many people found other pages of this blog trying to find more information about Unix sockets, and so I thought it’s about time we shed some light on this seeming mysterious, but really simple concept.
What is a Unix socket?
A Unix socket (the technically correct name for it is Unix domain socket, UDS) is a way of inter-process communication (IPC) in Unix. Like almost everything in Unix, a socket is a file. It’s a special file, to be precise. Unix processes which want to communicate between each other use special set of functions to access the special file of a Unix socket, and easily exchange data in both directions.
In very simple terms, a Unix socket is nothing but a byte stream – a data transfer between processes running locally or on networked Unix systems.
Examples of Unix sockets
Most well know examples of Unix sockets are probably those servicing the graphics system on your Unix box: X11 server socket and some optional sockets of programs managing it, like GDM (Gnome Desktop Manager).
GDM socket
bash-2.05b$ ls -al /tmp/.gdm_socket
srw-rw-rw- 1 root root 0 Oct 25 17:49 /tmp/.gdm_socket
bash-2.05b$ file /tmp/.gdm_socket
/tmp/.gdm_socket: socket
syslog socket
The message logging daemon, syslogd, uses /dev/log on most systems to accept new messages to be logged in log files. Here’s how this file looks in RedHat:
bash-2.05b$ ls -al /dev/log
srw-rw-rw- 1 root root 0 Oct 25 17:49 /dev/log
bash-2.05b$ file /dev/log
/dev/log: socket
Types of sockets in Unix
Here is another thing which can be quite confusing about sockets in Unix – the classification.
On the highest level, there are two types of sockets: Unix domain sockets for IPC (AF_UNIX) and Unix network sockets using Internet family of protocols (AF_INET), most commonly referred to as Unix Internet sockets.
These two types essentially define a set of communication protocols supported by a socket. Unix domain sockets are for IPC (interprocess communication) only, which means they can only be used for processes running locally on the same Unix system and communicating to each other. The Internet sockets support protocols which allow you to connect processes between different Unix systems: IP protocol for the network communication, and TCP/UDP protocols for the transport.
Connection-oriented and connectionless sockets
Both Unix domain sockets and Unix Internet sockets can use reliable (guaranteed) and unreliable (best effort) approaches for establishing and maintaining connections. With Unix domain sockets it doesn’t really matter, as all the communication is local to your Unix system, but with Internet sockets it’s a different story.
Connection-oriented sockets are called stream sockets (SOCK_STREAM), and are the reliable and guaranteed way to communicate. For Internet sockets, the TCP protocol is used to ensure that your data is confirmed to be delivered to the destination point, and your data packets will be received in the same order they were sent out.
The reason such sockets are called stream sockets is because your Unix will create and maintain a stream – an active connection between the source and the destination points, using TCP to manage this connection. All packets are automatically acknowledged and synchronization is maintained to ensure the ordered way of sending and receiving packets.
Connectionless sockets are called datagram sockets (SOCK_DGRAM) and they use UDP for their communication, which means that the packets of data which you send may or may not be received on the other end. Because there is no control over the transfer (no acknowledgments of the delivery, no ordered packet arrangements), there is no need to maintain such a connection. Hence the name – connectionless. You simply send a message out, and it’s then a problem of a higher level protocol to ensure the data is transferred successfully.
That’s it – should be enough for a brief Unix sockets introduction. Do ask your questions in the comments to this post, and I’ll be sure to answer them in future posts on Unix sockets – there’s still plenty to show and explain!
