Passing open file descriptors over unix domain sockets

Note:- This article is an example walk-through written for developers keeping in mind that you are aware of very basic network/socket programming concepts.

Some basics
All of you must have heard about file descriptors or popularly known as fds in Unix world. It is basically an index/indicator generally used to provide access to files, network sockets etc. File descriptor will always be a non-negative integer which has been part of POSIX standard from old days. Accordingly we have 3 standard POSIX file descriptors namely standard input or stdin with value 0, standard output or stdout with value 1 and standard error or stderr with value 2. Standard I/O library from C allows us to create fds via different system calls like open(), creat(), socket(), socketpair(), pipe() etc. For example, if we want to write some data into a file we normally invoke open(2) or create(2) to have an open file descriptor and subsequent write(2) operation is performed via that fd. Finally when we are done with operations we close the fd.

That’s all about some basic file operations work flow. On the other side we have Unix Domain Sockets which is commonly used for data communications between processes Continue reading

Mandatory locks support with GlusterFS v3.8


Latest version 3.8 from GlusterFS community comes out with the support for Mandatory locks. Please refer the blog post announcing the release to get an overview of all new features delivered with 3.8. This article will be a background cum architectural analysis on mandatory locks feature for GlusterFS and its further possibilities when working under various protocol environments.

Traditional/Advisory locks
Whenever it comes to a situation where file contents are being concurrently accessed by different applications there always raise the Continue reading

Systemd defaults KillUserProcesses to ‘yes’ in logind.conf with v230

Isn’t it strange what systemd has done with its latest release version 230 regarding user background process and login sessions? Or is it just me who feels so? Anyway in this post I am going to analyse this change[1] in default setting of logind.conf that upstream has released recently. Let me kick off with the following snippet taken from changelog of v230:

>>> systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of “no” is now changed to “yes”. This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout. <<<

Click here for complete changes with v230 release.

So what does that mean? I can explain the above change citing the example of GNU Screen. For an average GNU/Linux user it is not an Continue reading