Wandering Thoughts archives

I've become mostly indifferent to what language something is written in

In a comment on this entry, Opk wrote (in part):

Will be interesting to hear what you make of git-series. I saw the announcement and somewhat lost interest when I saw that it needed rust to build.

I absolutely get this reaction to git-series being written in Rust, and to some extent I share it. I have my language biases and certainly a program being written in some languages will make me turn my nose up at it even if it sounds attractive, and in the past I was generally strongly dubious about things written in new or strange languages. However, these days I've mostly given up (and given in) on this, in large part because I've become lazy.

What I really care about these days is how much of a hassle a program is going to be to deal with. It's nice if a program is written in a language that I like, or at least one that I'm willing to look through to figure things out, but it's much more important that the program not be a pain in the rear to install and to operate. And these days, many language environments have become quite good at not being pains in the rear.

(The best case is when everything is already packaged for my OSes. Next best is when at least the basic language stuff is packaged and everything else has nice command line tools and can be used as a non-privileged user, so 'go get ...' and the like just work and don't demand to spray things all over system directories. The worst case is manual installation of things and things that absolutely demand to be installed in system directories; those get shown the exit right away.)

In short, I will (in theory) accept programs written in quite a lot of languages if all I have to do to deal with them is the equivalent of '<cmd> install whatever', maybe with a prequel of a simple install of the base language. I don't entirely enjoy having a $HOME/.<some-dir> populated by a pile of Python or Ruby or Perl or Rust or whatever artifacts that were dragged on to my system in order to make this magically work, but these days 'out of sight, out of mind'.

There are language environments that remain hassles and I'm unlikely to touch; the JVM is my poster child here. Languages that I've never had to deal with before add at least the disincentive of uncertainty; if I try out their package system and so on, will it work or will it blow up in my face and waste my time? As a result, although I'm theoretically willing to consider something written in node.js or Haskell or the like, in practice I don't think I've checked out any such programs. Someday something will sound sufficiently attractive to overcome my biases, but not today.

(As mentioned, I generally don't care if the program is available as a prebuilt package for my OS, because at that point there's almost no hassle; I just do 'apt-get install' or 'dnf install' and it's done. The one stumbling block is if I do 'dnf install' and suddenly three pages of dependent packages show up. That can make me decide I don't want to check out your program that badly.)

In the specific case of git-series and Rust, Rust by itself is not quite in this 'no hassle' zone just yet, at least on Fedora; if I had nothing else that wanted Rust, I probably would have ruled out actively looking into git-series as a result. But I'd already eaten the cost of building Rust and getting it working in order to keep being able to build Firefox, and thus at the start of the whole experience adding Cargo so I'd be able to use git-series seemed simple enough.

(Also, I can see the writing on the wall. People are going to keep on writing more and more interesting things in Rust, so sooner or later I was going to give in. It was just a question of when. I could have waited until Rust and Cargo made it into Fedora, but in practice I'm impatient and I sometimes enjoy fiddling around with this sort of thing.)

This casual indifference to the programming language things are using sort of offends my remaining purist insticts, but I'm a pragmatist these days. Laziness has trumped pickiness.

(Not) changing the stop timeout for systemd login session scopes

I wrote earlier about an irritating systemd reboot behavior, where systemd may twiddle its thumbs for a minute and a half before killing some still-running user processes and actually rebooting your machine. In that entry I suggested that changing DefaultTimeoutStopSec in /etc/systemd/user.conf (or in a file in user.conf.d) would fix this, and then reversed myself in an update. That still leaves us with the question: how do you change this for user scopes?

The answer is that you basically can't. As far as I can tell, there is no way in systemd to change TimeoutStopSec for just user scopes (or just some user scopes). You can set DefaultTimeoutStopSec in /etc/systemd/system.conf (or in a file in system.conf.d), but then it affects everything instead of just user scopes.

(It's possible that you're okay with this; you may be of the view that when you say 'shut the machine down', you want the machine down within a relatively short period even if some daemons are being balky. And aggressively killing such balky processes is certainly traditional Unix shutdown behavior; systemd is being really quite laid back here. This is an appealing argument, but I haven't had the courage to put it into practice on my machines.)

As you can see in systemctl status's little CGroup layout chart, your user processes are in the following inheritance tree:

user.slice -> user-NNN.slice -> session-N.scope

You can create systemd override files for user.slice or even user-NNN.slice, but they can't contain either DefaultTimeoutStopSec or TimeoutStopSec directives. The former must go in a [Manager] section and the latter must go in a [Service] one, and neither section is accepted in slice units. There is a 'user@NNN.service' that is set up as part of logging in, and since it's a .service unit you can set a TimeoutStopSec in systemd override files for it (either for all users or for a specific UID), but it isn't used for very much and what you set for it doesn't affect your session scope, which is where we need to get the timeout value set.

If you want to use a really blunt hammer you can set KillUserProcesses in /etc/systemd/logind.conf (or in a logind.conf.d file). However, this has one definite and one probable drawback. The definite drawback is that this kneecaps screen, tmux, and any other way of keeping processes running when you're not logged in, unless you always remember to use the workarounds (and you realize that you need them in each particular circumstance).

(I don't know what it does to things like web server CGIs run as you via suexec or processes started under your UID as part of delivering mail. Probably all of those processes count as part of the relevant service.)

The probable drawback is that I suspect systemd does this process killing in the same way it does it for reboots, which means that the default 90 second timeout applies. So if you're logging in with processes that will linger, you log out, and then you immediately try to reboot the machine, you're still going to be waiting almost the entire timeout interval.