Talks
Unicorn Unix Magic Tricks
Summarized using AI

Unicorn Unix Magic Tricks

by Thorsten Ball

The video titled "Unicorn Unix Magic Tricks" by Thorsten Ball at the wroc_love.rb 2015 event explores the functionalities and implications of using the Unicorn web server, which is designed for Ruby on Rails applications. In the talk, Thorsten likens Unicorn's capabilities to magic, emphasizing how it leverages Unix principles for enhanced performance and scalability.

Key Points Discussed:

  • Introduction to Unicorn:

    • Unicorn is a Ruby web server utilizing a master-worker architecture with hot reloading capabilities.
    • The speaker shares his background as a Rails developer and his experiences contributing to Unicorn's development.
  • Unix Fundamentals:

    • Thorsten outlines essential Unix concepts and functions that underpin Unicorn's features, including the fork system call which is critical for process creation.
  • Using Fork:

    • He demonstrates how fork is implemented in Ruby and how Unicorn uses it to manage worker processes efficiently.
  • Communication Mechanisms:

    • Thorsten discusses the use of pipes for communication between processes in Unicorn.
    • He explains how pipes allow workers to communicate with the master process effectively, illustrating this with a Ruby example of inter-process communication.
  • Socket Management:

    • The speaker elaborates on the role of sockets for networking in Unix systems and how Unicorn uses sockets to handle web connections.
    • The use of the select system call for monitoring file descriptors to manage multiple connections concurrently is highlighted.
  • Signal Handling:

    • Signals are discussed as a means of process management in Unix, with specifics on how Unicorn manages signals to maintain operational efficiency without abrupt terminations.
  • Unicorn's Features:

    • Key features of Unicorn include:
    • Preloading: Loading of the application into memory for faster process booting
    • Worker Scaling: Dynamic adjustment of worker processes through signals
    • Hot Reloading: Seamless deployment of application updates without downtime

Conclusions and Takeaways:

  • Understanding Unix principles is crucial for developers working with Rails, as it enhances debugging processes and application performance.
  • Learning about forking, sockets, signals, and their interactions can lead to more efficient application architectures.
  • The intricacies of Unix, as demonstrated through Unicorn, showcase how lower-level knowledge can significantly impact high-level application development.
  • Thorsten encourages further exploration and discussion of these concepts, inviting questions from the audience to deepen understanding.
00:00:08.560 Hello everybody, my name is Thorsten Ball. I'm a software developer from Germany. I program in Ruby, Go, and sometimes in Lisp. On the left is my name on GitHub and on the right is my name on Twitter. I work for a company called Fling in Germany as a Rails developer, and we do dynamic ride-sharing as a web application. The name of this talk is "Unicorn Unix Magic Tricks," which is quite a mouthful, and actually a weird title. Allow me to explain.
00:00:32.770 Unicorn is a web server written in Ruby for Rack and Rails applications. When I first encountered Unicorn, it seemed like magic to me. Unicorn had all these amazing features, like a master-worker architecture, where you had one master process and multiple worker processes. It had hot reloading, which allows Unicorn to reload a new version of your application while the old one is still running, enabling it to serve all requests while the new version boots up. This felt like magic to me.
00:02:14.530 Unicorn also had several interesting signals you could send, such as the TTY signal to increase the number of workers, the USR2 signal for hot reloading, the HUP signal to reload the configuration, and the QUIT signal for a graceful shutdown. Additionally, Unicorn featured preloading, which allowed it to preload my Rails application—taking around 10 seconds to load—into memory and spawn new worker processes in approximately 50 milliseconds. All of this seemed magical to me at first, but as I explored Whisper's source code, I discovered that it all relied on Unix.
00:02:40.960 Many of you know Unix from the user's perspective—you use the shell, command line, pipes, redirection, and so on. However, there is also a developer's side of Unix, which you can leverage in your programs. In this talk, we're going to look at how Unicorn employs Unix to build its exceptional features. We'll explore some basic Unix tricks and principles, see how they work, how we can use them, and how Unicorn utilizes them.
00:05:05.750 The first Unix trick I want to talk about is the 'fork' function. Every process on your Unix system, except the first one, is created by a call to fork, which is a system call documented in section 2 of the Unix manual. System calls represent the API of the kernel. When you call fork, the kernel splits your process into two: a parent process and a child process, where the child is nearly an exact copy of the parent, including the data, stack, heap, environment, user ID, and current working directory.
00:07:40.680 Using fork in Ruby is straightforward; we use the 'fork' method. In an example, after calling fork, we have two processes: a parent and a child process. The parent must wait for the child to finish execution to avoid becoming a zombie process—this is a technical term in Unix. The parent prints something after the child finishes, and if you run this, you can see that the output of the child process matches the parent process ID. With this single fork call, you have created two processes.
00:08:09.480 Unicorn leverages fork in a similar manner. Its method called 'spawn_missing_workers' creates each worker in a loop by calling fork multiple times. The parent process takes the returned child process ID and saves it, while the child enters a worker loop. After this call, you'll find 16 worker processes doing their tasks while the parent process handles work concurrently.
00:09:03.660 Now, let's discuss another Unix trick: pipes. You have probably used pipes before, where the output of one command becomes the input of another. However, we can also use pipes outside the shell with the 'pipe' system call, which gives us two file descriptors—one for reading and one for writing. File descriptors are numbers pointing to a file entry in the kernel. Since child processes inherit these file descriptors, pipes become an excellent means of communication between processes.
00:10:22.320 In Ruby, we start by calling IO.pipe, which eventually invokes the pipe system call and provides us with read and write ends. Once we close the read end in the child process, we can write a message to the write end and close it after sending. The parent process needs to wait for the child to exit and closes the write end. Then, it reads the message from the child process. This approach allows us to communicate effectively between two processes. Unicorn employs pipes extensively to manage its worker processes.
00:11:54.340 For instance, when you configure Unicorn to use 16 worker processes, it opens a separate pipe for every connection between one worker process and the master process. Thus, there will be 16 pipes through which the master communicates with the workers. Unicorn also implements a self-pipe used by the master process to communicate with itself. An interesting application of pipes arises when you start Unicorn as a daemon process, meaning it runs in the background and isn't attached to the terminal.
00:15:00.820 To detach from the terminal correctly, you must call fork twice, creating a grandchild. Unicorn utilizes a pipe to communicate with the grandchild. Once the grandchild sends a message indicating that it is fully booted up and ready to go, the master process will exit and detach from the terminal. This use of pipes helps synchronize the booting of a daemon process.
00:17:18.700 Next, let's discuss a basic Unix principle: sockets. Sockets are essential for networking in a Unix system. They represent connections, and there are various types including TCP, UDP, SCTP, and raw sockets. In Unix, everything is treated as a file, meaning that sockets also behave like files. As such, child processes inherit sockets just as they do file descriptors.
00:20:35.800 For web servers, like Unicorn, you must go beyond simply calling socket system calls. The basic Unix networking socket lifecycle involves creating a socket with the socket system call, binding it, and then listening for incoming connections. The listen call initializes the socket, effectively turning it into a passive server socket that accepts connections. Additionally, we must use the 'accept' method to get new connections, which blocks until a new connection is available.
00:23:07.140 However, blocking on a socket makes it challenging to manage multiple connections. This is where the select system call steps in. Select monitors file descriptors, returning when one or more are readable or writable, effectively allowing multiplexing. Using select, we can replace blocking accepts, creating a fully functional multi-process TCP server with relatively few lines of Ruby code.
00:25:36.590 Unicorn employs the same strategy, creating a listening socket and utilizing the select method to distribute connections among its workers. When Unicorn initializes, it establishes a listening socket and pipes for worker communication. Each worker calls IO.select to monitor the listening socket and pipes to ensure it doesn't miss messages from the master process.
00:28:30.110 Additionally, let's talk about signals. Many of you have probably used signals to kill processes. A signal is a software interrupt that gets delivered to a process through the kernel. Signals have various actions, such as quitting or cleaning up, and can be defined in the kernel. For example, if a process receives a quit signal, it can gracefully handle the signal by cleaning up resources instead of abruptly exiting.
00:30:22.150 In Ruby, you can easily handle signals using the 'trap' method, allowing you to execute specified actions upon receiving signals. However, Unicorn has its own extensive signal handling mechanism. It creates a self-pipe that captures signals, allowing it to maintain control while efficiently managing signals to handle state changes.
00:30:58.790 It does this by writing the name of the received signal to a queue. When the master process detects a signal in its main loop, it's awoken and acts on the signal accordingly, turning signals into a synchronous stream of events for straightforward processing. All of these components—forking, sockets, selecting, and signal handling—are fundamentally simple yet come together to give Unicorn its rich set of features.
00:33:04.290 Now, let's take a look at Unicorn's extraordinary features, starting with preloading. Preloading allows Unicorn to load the Rails application into memory once, enabling faster worker process startup. The master process sets up a lambda to handle loading, and when you instruct Unicorn to preload, it simply calls fork, and the child processes inherit the loaded memory. This innovative approach makes Unicorn’s scaling and performance improvements quite impressive.
00:34:37.550 Another fascinating feature provided by Unicorn is worker scaling through signals, enabling the addition or removal of worker processes seamlessly. The master process is responsible for managing the total worker count, creating new workers when needed or gracefully shutting down ones that are no longer necessary. This mechanism ensures Unicorn maintains optimal performance while being resource-efficient.
00:36:20.570 Lastly, hot reloading is a standout feature sometimes deemed as zero-downtime deployment. Unicorn achieves this by starting a new master process while the existing one continues to operate, allowing for deployment of new application versions without request interruption. This complex functionality is achieved using previously established mechanisms, such as signaling, forks, and pipes.
00:37:59.510 With hot reloading, the master process spawns a new child and, if successful, the new master can seamlessly take control of the same sockets as the old one, ensuring continuous service without service disruption. All of these enhancements exemplify how Unicorn has combined simple concepts into powerful features.
00:38:26.470 Before concluding, I'd like to emphasize the importance of understanding these concepts for application developers. Debugging Rails applications often occurs on Unix-based systems, so knowledge of this environment better prepares you to tackle production issues. Furthermore, understanding how processes communicate and how system calls operate helps in designing more efficient applications.
00:39:41.470 By knowing how these lower-level details influence your application, you can make better architectural decisions that align with performance requirements. Ultimately, learning about these principles has greatly benefited my own programming skills, enriching my work with Ruby and Rails due to a deeper understanding of their underlying systems.
00:41:18.000 I appreciate your attention and invite everyone to ask questions or delve into discussions about low-level programming, Unix, or Ruby. Thank you for listening.
00:43:20.590 Do we have any questions? Yes, the first part is about hot reloading. It raises a concern about whether killing the parent would leave the new process as a zombie process. Generally speaking, it is uncommon to kill your own parent process, which is something that can confuse the system. Most users leverage orchestration tools to manage old processes after the new ones are booted.
00:45:47.900 The second part of the question touched on whether multiple processes can share a socket. With modern Linux, and even FreeBSD, it's feasible to have separate processes use the same socket, although the socket must be appropriately configured to allow this interaction. You can also send file descriptors between processes, which opens additional avenues for inter-process communication.
00:48:20.000 Thank you all for your participation and insightful questions.
Explore all talks recorded at wroc_love.rb 2015
+2