jjacky.com

One thing that happens when you come to Linux from Windows, is you start seeing the different parts that make up your system. For instance, on Windows when you power up your computer, you have a boot logo, then you enter your password and there's your desktop. All of that, like the rest, it's all "Windows".

You don't have to known about the different parts of that whole process, and Microsoft usually likes to hide it from you anyways. In Linux, it's not that you need to known about them, but you can. And with Arch, chances are you will.

It's not a bad thing though, far from it, because as with pretty much everything else on Linux, if there's something you don't like, you can change it. Chances are there are a few alternatives our there, and if not and assuming you have the knowledge and time for it, you can also just make your own replacement.

(Also, you can sometimes get rid of things you don't need. I never had any use for a desktop, it's always been useless to me, only used by software installers that either didn't respect or didn't bother asking about putting shortcuts there. And now, I just don't have one. No change for me, except a few MBs of disk space & memory saved!)

Display Managers

And so I discovered the notion of Display Managers (DM), those little login screens where you enter your login/password and that then start your XFCE session, or whatever DE/WM you're using. Having a DM is not a requirement, you can simply log in as always and manually type startx to get things started. (You could also use an alias, like x or something, if you're lazy. I know I am.)

Originally I started installing GDM only because I knew it a little (as in, I've tried Fedora a little before), and it does look nice. But as I did that I also realized that it came with a few dependencies, and thinking about it, I wondered: why? Why would I need all that, for just a pretty window asking for my login & password?

So I removed it, and switched to XDM instead, which after a few tweaks did not look too bad, and worked just as well. Also, it required much less disk space (well, it's relative of course) than GDM. But the truth is, the question pretty much remained.

Who needs a DM anyways?

It's not that XDM needs a lot of disk space, or RAM, but it obviously needs some. And it is always running, even though I only need it for a few seconds every once in a while (I don't turn my computer off very often...), so all in all, it all seems like a waste. Maybe not a big one, but one nonetheless.

It is entirely possible that there's more to a DM than what I think of right now, and/or that there are things it does/allows that I haven't (yet) discovered/thought of, but as far as I can see, all I need from the DM is to log me in and start X(FCE); that is, call startx (and while I don't actually use a session manager, I don't think it would change anything if I did.)

Looking around about all that, two things made me get rid of XDM, and not use a DM in the end. First of all, I started to wonder about what I would have to do whenever there would be an update of X. I was already aware that I needed to quit XFCE and all I had running there, which I'm not too happy about_(*)_ but hopefully it's not updated every week, but would I also have to end/restart XDM? Then it's starting to become a little annoyance.

(*) By which I mean, while it surely doesn't require as much time, it pretty much feels the same as needing to reboot the whole computer as far as I'm concerned. I still need to close every application I have running and start over...

And of course, I figured out that using a little bash script, I could make it so that upon login, XFCE would be started automatically without me having to even press a single key! So really, who needs a DM?

.bash_profile

So how does this work? I simply added a little something in my .bash_profile so that X would be started automatically when I log in, but adding a couple more requirements:

• only if I'm logging in on tty2 (where I usually log in). This is so I can still log in and stay in console, or open one alongside my XFCE session, should I need to.
• only when the runlevel is 5. This isn't really needed obviously, but I figured I'd still use level 5 with the auto-launching of XFCE.

Here's the result:

1. level=$(runlevel)
2. if [ -z "$DISPLAY" ] && [ $(tty) = "/dev/tty2" ] && [ "${level:2:1}" = "5" ]; then
3.     exec startx -- vt7
4. fi

Now, I believe there might be an "issue" in that, while XFCE is running and everything, one could switch to tty2 and hit Ctrl+C to "mess things up". Because exec is used you would go back to the login screen - you don't get a shell, which could then also be a security risk - but it would "crash" X and everything that was running in there.

It might not be a good thing, however it doesn't bother me in this case, and on the other hand I do like the fact that I can switch to tty2 to:

• go see any potential (warning/error) messages. I known anything important should find its way to /var/log/Xorg.0.log anyways, but not everything does, and I guess I like the idea of being able to see such things, just in case. (It's also why I do my logging in on tty2, and force X to start on vt7 : I like the idea of keeping my boot messages on tty1. Just in case, and because sometimes some things don't get to go to /var/log/boot.)
• hit Ctrl+C and "kill everything" in there. It's probably not gonna be something I'm gonna need to do a lot, hopefully pretty much never, but if somehow I manage to get a system unresponsive or something, I can switch to tty2, hit Ctrl+C, and that should reset things without the need to actually reboot.

xlsh - eXtended Login Shell

This was all fine and working, and then I found out about xlsh, the "eXtended Login Shell" that fellow Arch user Michał Siejak shared in the forums. It isn't a DM, but a login replacement. It's a small and simple tool that can actually also be used to replace your DM, since it has support to work in X, however I'm really not interested in that part.

No, what I like is that it will present a "pre-login shell" with basically three commands: login to log in, of course, but also reboot and shutdown to do just that.

So this would give me the only thing I actually missed from a DM, which was the ability to reboot or shutdown the computer from there and without the need to log in first (and sudo). In other words, it was the perfect addition to my setup. All it takes to make it work is edit /etc/inittab and replace the line of the tty where you want it active with something like this:

c1:2345:respawn:/sbin/agetty -8 -s 38400 -n -l /usr/sbin/xlsh tty1 linux

When using it, I did however found what I believe to be a little bug, in that signals that are blocked by xlsh are not restored upon login, and so for instance all SIGINTs were blocked when logging in through xlsh; Which I believe is a problem, certainely was the case for me. So I did fix this, and while at it I removed two things (or, added compilation options to do so) because I liked it better that way :

1. no more login completion. Just because. 2. no more X support. This is because I have no use/interest for such a thing (All it does basically is start X, and start a terminal to have xlsh running in there. I'd rather have xlsh directly on tty and not waste any time or ressource.), but also because the PKGBUILD had a few extra dependencies due to this that I didn't want to bother with (xterm, xdotool, xorg-xsetroot, xorg-xwininfo, xorg-xmessage and xorg-xrdb).

So, if you're interested in xlsh you can find the official package here (from xlsh's author masterm); or you can find my version without X support here.

And if you do use the official version, note that signals are blocked so you might want to use this patch to fix it:

1. diff -r c2c082c4832e -r 0906dbb5f675 include/libxlsh.h
2. --- a/include/libxlsh.h Tue Nov 15 13:02:40 2011 +0100
3. +++ b/include/libxlsh.h Tue Nov 15 13:23:37 2011 +0100
4. @@ -24,6 +24,7 @@
5.  
6.  size_t libxlsh_strnlen(const char* s, size_t maxlen);
7.  void   libxlsh_proc_sigmask(void);
8. +void   libxlsh_restore_sigmask(void);
9.  pid_t  libxlsh_proc_exec(const char* cmdline, int flags);
10.  pid_t  libxlsh_pid_read(const char* filename);
11.  int    libxlsh_pid_lock(const char* filename, pid_t pid, int flags);
12. diff -r c2c082c4832e -r 0906dbb5f675 src/libxlsh.c
13. --- a/src/libxlsh.c     Tue Nov 15 13:02:40 2011 +0100
14. +++ b/src/libxlsh.c     Tue Nov 15 13:23:37 2011 +0100
15. @@ -32,6 +32,11 @@
16.    sigprocmask(0, NULL, &xlsh_default_sigmask);
17.  }
18.  
19. +void libxlsh_restore_sigmask(void)
20. +{
21. +  sigprocmask(SIG_SETMASK, &xlsh_default_sigmask, NULL);
22. +}
23. +
24.  pid_t libxlsh_proc_exec(const char* cmdline, int flags)
25.  {
26.    pid_t pid;
27. diff -r c2c082c4832e -r 0906dbb5f675 src/xlsh.c
28. --- a/src/xlsh.c        Tue Nov 15 13:02:40 2011 +0100
29. +++ b/src/xlsh.c        Tue Nov 15 13:23:37 2011 +0100
30. @@ -330,6 +330,7 @@
31.      if(*terminal)
32.        setenv("TERM", terminal, 1);
33.  
34. +    libxlsh_restore_sigmask();
35.      execlp(session, _arg0, (char*)0);
36.      exit(EXIT_FAILURE);
37.    }