[BUG] m key hangs terminal after unexpected power loss
I much prefer complicated systems which I can fix myself, even at the cost of some stability. In a recent client project I spent some time emailing logs back and forth with the developers of a proprietary piece of hardware to get acknowledgement that an issue even existed, let alone fixed, without ever being privy to the internal workings that caused the problem in the first place. It’s a frustrating and disempowering experience, particularly for someone used to picking things apart to make them work.
In contrast, though they are very much of my own making, problems on my Linux system aren’t frustrating at all to resolve. I first discovered my peculiar issue trying to open my music player, which failed to start reporting that MPD wasn’t available. Typing in mpd to start it I found an unresponsive terminal, though on starting new instances I was able to run commands starting with other letters. MPD does start with m, could these things be related?
A Linux terminal is composed of a few different parts, but the one that handles key inputs is the shell, the specific one I use being the fairly popular Zsh. It’s highly configurable, and sure enough I have highly configured my installation, though said configuration has been more or less stable for years and I try to avoid updating anything if I don’t have to. Nonetheless, launching Zsh without my configuration with zsh -f made the problem go away, so I was on the path to a root cause.
One of the few parts of my system which is allows semi-automatic updates is OMZ, a configuration framework for Zsh. OMZ being the only thing I know to have changed recently made me immediately suspicious of it. It had asked for an update which I allowed after booting yesterday, so I was currently on the first boot post-update; here be demons. And sure enough, toggling off the line that invoked OMZ in my configuration also made the problem go away, so it lay within the wheelhouse of OMZ, rather than Zsh itself.
I skimmed the project’s GitHub issues, but nothing reported in the ppast few weeks looked similar to my experience, so given the framework’s popularity it seemed improbable that I was looking at an OMZ bug, despite the deplorable automatic updates. And the MPD failure looked more like a smoking gun than a red herring, it was much more likely that something had gone awry locally than upstream, so I switched tack.
Since I could type m and therefore launch MPD in a config-less shell, I tried just that and was told the music folder /nas/Music was unavailable. Network trouble, I’ve had this before! My music collection lives on a NAS, but this was powered on. Indeed, I had used it on foobar2k minutes before on the other side of the dual boot. So the NAS is up and the network is working, it’s just that MPD can’t see it.
The solution was coming into view, though I didn’t have all the pieces yet. In testing a slightly dodgy electrical appliance a few hours prior my housemate had tripped the fusebox, shutting down anything without a battery - including the network’s router - instantly. As things rebooted and came back online, some IPs addresses got shuffled around, making my /etc/hosts file out of date. Finding the NAS again nmap -sn "192.168.0.*" and updating thte hosts file meant I could start MPD again, and sure enough I could type m into Zsh once more.
The m, as it turned out, was not from MPD but from music - specifically, the ~/music symlink I had made after doing some internal organisation of my music folder. This explained why I hadn’t encountered the problem in previous network outages. There is probably a way to make that more robust, but now that it’s working again I’ve no motivation to try. Thus, my spinning-plates operating system, despite my best efforts, continues to be an abundant source of weird and wonderful surprises.
I don’t claim to be any good at Linux or computers generally, and this is a class of problem that I can’t imagine encountering on Windows, wherein the equivalent network setup is much more resilient (how do I update the address /etc/hosts automatically if it changes? Probably scripting nmap?). However, resolving my dodgy m-key problem was silly, fun and took about 15 minutes from end-to-end. Emailing logs to remote developers took weeks, and I still don’t know what the problem actually was, despite working with the technology to make my living. I don’t like trying to fix problems at a distance and I’m suspicious of any software I can’t look inside of - my processor, my rules. So, looking to the future, I’m doing my best to train for and seek work that doesn’t carry the risk of such closed technology. It’s maybe a little idealistic, but I’d like to hope for a sillier, more open future all the same.