This would be a sorta longish thread about the recent decision to sell/scrap INS Vikrant(Indian Air Carrier) and some of the things I found about systemd while using it.
First up, It has been reported in the media that INS Vikrant would be scrapped, ostensibly because the Maharashtra Govt. could not maintain it. The real reason I fear is that both the Central and State Governments had never any interest to maintain the ship which had been turned into a museum. I live in Pune, which is around 200~250 kms. from Mumbai. Since 1997 till December 2013 I have been to Bombay/Mumbai at least 10 times if not more. During the course of those visits for personal or professional reasons, whenever I got the chance I wanted to see the ship-turned-museum, but every-time was not able to as it used to be invariably be closed for something or the other. This sort of apathy towards our own defence, the lack of inculcating a sense of pride for our navy in citizens and for our defence equipment can only happen in India.
This episode reminds me of a similar experience I had years ago which I had in Goa. Near the old Goa airport there is/was a naval museum. I don’t remember it’s name as it was several years ago. It was on land and maybe 3-4 rooms on the ground floor. To guide the people to the various exhibits and share a sense of history and pride, there was NOT a single naval officer to tell people about the various instruments and the science behind them in those rooms ensuring that our people became aware, at the very least on a superficial level about what our defence capabilities are and what the off-shoots of such R&D for the society at large. There is/was lot of science and potential to make it really into an attraction but both the Government of the day (BJP) as well as the naval officers who felt giving/sharing information with the general populace was below dignity which resulted in such sub-standard experience for everybody (including me). The fact that the Congress party does this in Maharashtra is no different then them. The dis-interest by the administration could be gauzed from the fact that not a single restaurant (of any repute) in the vicinity of the museum (the Goan one) and for several kilometers.
Also there was no attempt made to sell any sort of books relating to the subject or/and engage people in any meaningful way. To make a comparison, if you look at IUCAA which is about astronomy in Pune, you will find a talk on galaxies at least once a month (of international repute). I am comparing just on two sciences and the scientific temper. The whole atmosphere in the Goa Museum was slightly depressive. From a little bit of social engineering I was learnt that, at that time the ‘museum’ was a sort of collaboration between the Center and the State and because of their in-fighting and whatever, they had a non-existent budget and were unable to get the salary on time for the people working there. This was quite a bit of a shocker to me as till that time I had not become so cynical about either the state or the way things were/are and had huge regards for our brothers at sea. Now whether it was an institutional or a process issue or something else I had neither the time or inclination at that time to find out.
I did feel however, that a huge opportunity to educate, share was being lost to generations of children and future members of the society. And now to hear this, this just makes me sad.
Edit: Just came to know of a change.org petition as well but as can be seen it’s not in public consciousness at all. The only comments are from people who had either served on their ship or somebody’s near or dear one.
Anyways, before I become more sad, let’s cut to something a bit positive. Sometime back, I had changed my init system on my system (a desktop PC running Debian testing) from sysvinit to systemd and got some interesting results with the change which I want to share.
Before going further, let’s try and understand what init is/does. The following usually happens when you start/power up a GNU/Linux machine.I am assuming a traditional desktop/laptop system here. In other hardware architectures, the process might be same or different depending on lot of factors for which I do not want to get into any detail and there are lots and lots of hardware architecture. Anyways without further ado :-
a. The system on powering up performs a POST test and checks that all the components of the systems (including peripherals which are connected to the system) or rather the motherboard are in working order and connected properly. This usually happens behind the scenes and the only time you come to know is when either you get error message or some beeping sounds. For e.g. when some internal wiring connection gets loose or some hardware has some problem. There have also been times though that due to BIOS bugs you could not see RAM, memory or USB in a system but that’s a different topic altogether. A simple BIOS update (or not so simple) could fix things (or not) but that’s getting a bit off-topic. Nowadays something EFI or UEFI does this and more. I do not want to spend energy on changes from BIOS to UEFI so would leave it at there.
b. Then the system searches for the legacy MBR (Master boot record) on the HDD(hard disk) of the system. In newer hard disks/block devices (2 TB and more) legacy MBR (or Protected MBR/LBA0) is usually not used (unless BIOS is there – a rare case) and instead you have Partition table header (LBA 1) where the boot record would be kept.
Note :- To manage these newer hard disks it is quite a recent phenomenon as far as support in most of the GNU/Linux tools for GPT is concerned, as the same has come in the last few months but that again is going off-topic.
Anyways, the LBA 1/LBA 0(MBR) depending on the HDD technology looks out for a boot loader (in our case it would be either GRUB or LILO), in other cases whatever name the boot-loader of whatever OS is used and tries to load the kernel. If the boot-loader is missing, it would give an error message and you can’t go any further. While in GNU/Linux this can be fixed by running a live GNU/Linux external ISO image and installing the boot-loader on a mounted hard disk partition but then again I’m going off-topic.
c. Once you get to the boot-loader you get various options and you select a kernel version that you want to run. In MS-Windows at least because both are at default values you generally see neither of them unless the last boot was a failure (or had some issue). My last real experience with MS-Windows was on Windows XP so have no authority if the same behavior persists/ed in Windows 7 and later or not (and frankly do not care.)
On GNU/Linux however, the kernel in-turn boots/mounts/initiates an initramfs and the succeeding init process before booting the rest of the root file system and drivers. Part of this booting can be seen if you disable the splash-screen and see the boot happening and the various part of drivers being loaded in User space as well as the rest of things in the root file-system.
d. After all that is done, you are either dumped on the console or a GUI login screen (powered by some $display manager) which asks for your login credentials and after accepting gets you access either to the modern desktop or/and the shell terminal.
Now if you want to try out systemd, what you need to do in order to get systemd is install it. If you are on big window managers like GNOME or KDE there are at least 4-5 binaries that you need to install.
$ sudo apt-get install systemd libpam-systemd
The above two are the least/minimum packages that you need to install to have systemd running on your system. In fact systemd itself is enough but if you are using gdm3 then you need libpam-systemd. I have been hearing rumors of kdm also going the same way (using libpam-systemd) but have no idea.
When you install that, 2-3 libraries are also installed along with it. For e.g. libsystemd-journal0, libsystemd-daemon0 are some of the libraries which tag/come along systemd.
The first thing you can do before making any change is install a package called psmisc and run pstree on the system. This is from the manpage of pstree :-
pstree shows running processes as a tree. The tree is rooted at either pid or init if pid is omitted.
The output when you run pstree should come out as something like this :-
I have shared a small extract of the pstree as just wanted to share that init/sysvinit in this case is the first process (the grandfather of all processes in user space). All the others, which were listed below init, for e.g. , the accounts daemon (which is responsible for all users and user accounts), acpid which is responsible for both device configuration as well as the various device power consumption patterns, anacron for running jobs and services at pre-determined times and lastly at-spi which is used as an assistive technology for differently abled people are derived or are children of sysvinit.
In some sense “It’s kinda the one ring to rule them all” (obviously derived from LOTR) .
Now the old init (it’s been there for more than a decade) which has been likened to an old vehicle whose engine is stuck together by tape and other things. The engine in this analogy is the systemv init. It works but needs lot of work and is not suitable for today multi-processor, large RAM’s and parallel execution note today. Also init has been known to suppress lot of information. For e.g. :-
$ sudo /etc/init.d/gdm3 status
[sudo] password for shirish:
[ ok ] gdm3 is running.
As can be seen it just replies that the service is working. If the service was not, the only option used to be stop the service and try reloading and then restarting the service. The only way to figure out if a service (like that) would have been to either use strace or gdb or some other tool to ascertain things and it simply used to take a lot of time troubleshooting.
Now the first thing to do is tell the boot-loader to stop using sysvinit and load systemd instead.
This is done by changing the file at /etc/default/grub and esp. this line.
The quiet parameter is for the splash-screen. As I do not want the splash-screen my /etc/default grub contained :-
In fact I don’t know if the last line is even there or not.
Anyways the change I did on my system is :-
Note :- Basically many of the apps. in Debian are now IPV6-aware but our ISP’s are not (at least where I live) so in order to conserve both power, bandwidth and security I disabled IPv6 . The other is telling grub that init henceforth would be found at /lib/systemd/systemd. The next line is for my convenience for debugging services if and when a service gets an issue. The other obvious benefit is we get better info. as will be seen later.
Now once those changes are done, you save the file and do :-
$ sudo update-grub
The output will come something like this :-
$ sudo update-grub
Generating grub.cfg ...
Found background: /usr/share/images/grub/Moraine_Lake_17092005.tga
Found background image: /usr/share/images/grub/Moraine_Lake_17092005.tga
Found linux image: /boot/vmlinuz-3.11-2-amd64
Found initrd image: /boot/initrd.img-3.11-2-amd64
In my case I have also added an image background to grub so grub is pretty-looking but that again is going off-topic.
The output is pretty simple. It tells the various things it finds.
Note :- update-grub or update-grub2 whichever you run makes a grub 2 config file by running
$sudo grub-mkconfig -o /boot/grub/grub.cfg
Because people are familiar with update-grub as were using the above command throughout the grub1 series (well over a decade) it made sense for the debian developers (and perhaps upstream developers as well) so the stub remains.
Now to find out if the magic has worked or not, reboot the
system and let it boot. The boot process order as well as the look of the boot process would have changed quite a bit when changing from sysvinit to systemd. Once inside on either the shell or on the desktop (running a terminal emulator) see again the output of pstree :-
As can be seen we are running systemd :). Now let’s do another test:-
$ sudo service gdm3 status
[sudo] password for shirish:
gdm3.service - LSB: GNOME Display Manager
Loaded: loaded (/etc/init.d/gdm3)
Active: active (running) since Sat 2013-11-30 23:22:29 IST; 4 days ago
├─ 1058 /usr/sbin/gdm3
├─25520 /usr/lib/gdm3/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displays/_0
├─25525 /usr/bin/Xorg :0 -background none -verbose -logverbose 7 -core -auth /var/run/gdm3/auth-for-Debian-gdm-lCDoQi/databa...
└─25719 gdm-session-worker [pam/gdm3]
As can be seen systemd is much more verbose than init. It not only tells that the service is running but also information about from when the service is running (in this case 4 days) as well as gives PID of the various child processes as well. In fact, as I have turned on verbosity for debugging, the output is much more but for our purpose this is good enough.
One of the other things that systemd has going for it is it’s support for cgroups or control groups. For years, if you wanted to have limited memory or have the most memory (for e.g. compositing/rendering an animation/image in GIMP or blender) there was no way to make sure it didn’t bog down the whole system (at least not with any certainty). With control groups you can assign say 1 GB of RAM and say only 1 CPU of the number of CPU’s in your system so that the system never chokes.
Note :- In the near future quite a few of the utilities, for e.g. ACPI will be fully merged in a future release of systemd.
Now one of the great things that systemd has, if it becomes the init system of today in the near future is that packages will be relatively lighter than the shell scripts which are used for starting or shutting down services. They are also heavily patched up. Also systemd service unit files have a very simple syntax. Here is an example service file :-
/etc/systemd/system$ cat syslog.service
Description=System Logging Service
It just starts a socket for syslog or in this rsylog in daemon form. That 6-8 lines of code is enough instead of the black magic and monstrosities made by the various shell scripts. If you are on Debian and specifically on Debian testing you can find it in /etc/systemd/system/syslog.service. Just doing a simple cat should produce the contents of the above file.
Now the big downside (or upside depending on how you look at it ) is there are lots of service files that need to be written if systemd is to be the hero. At last count almost 18k service files would need to be written if systemd has to shine.
Incidentally, there has been a debate within debian.org as to which init system should take place. Sysvinit is passe, so the contenders are systemd, upstart and OpenRC, one of these three. OpenRC hasn’t come out of new queue as of yet. As I have shared a bit of systemd goodness you know where my bias would be. Still would encourage to visit the Debate for initsystem.
That’s all for today.