Wandering Thoughts archives


Systemd needs sensible, non-truncated output

If you run 'systemctl status <service>', you get (among other things) some recent log messages from the service in question. Well, in theory you get that. In practice, well, here is part of what one of my machines shows:

Jul 15 17:18:20 mumble123.cs.toronto.edu unbound[31622]: [31622:0] notice: in...


What's Unbound trying to tell me? I have no idea because systemd has truncated the output in a useless way. I don't believe in truncating output by default to start with but if systemd is going to do it it should do it intelligently. Almost all of this line is useless. Especially useless is the huge hostname, because by definition systemctl is reporting on things from the local machine.

Of course, you may say, systemd is really just reporting some lines from syslog and chopping them off at 77 characters and thus the formatting is not its fault. Well, actually, it is. If systemd is going to truncate the output at all, it has to take responsibility for the formatting of the whole thing; effectively the rule is 'you break it, you own it'. Truncating the output is breaking it, so it becomes systemd's job to make it useful again.

Unfortunately this isn't a small issue. If you have a service that doesn't start, these very log messages may contain important information, information that systemd by default won't show you. You can make systemd show you in various ways (piping the output to something, remembering the --full argument, and probably others), but speaking as a sysadmin, you shouldn't have to remember any of this. Systemd should do the right thing by default because sysadmins already have enough to keep track of and truncating the output (especially in useless ways) is almost never what we want.

linux/SystemdSensibleOutput written at 23:54:06; Add Comment

Git's petty little irritation for me

Perhaps the most common thing for me to do with people's source code is to add my own purely local changes. When the source code is in a source repo, the simplest way of doing this is to just pull a copy of the source repo and then make my own changes on top. Then sooner or later I want to update my local repo by pulling in the latest central changes.

With CVS, SVN, and even Mercurial this more or less just works, however theoretically unclean and evil it is; all three detect that I have uncommitted local changes and attempt to re-apply them on top of the updates. Usually this succeeds and if it doesn't, the convention is to stick glaring markers in the files and leave it to me to fix them up. Git insists on doing the right thing in that at least by default it utterly refuses to try to merge my uncommitted changes with the remote updates it's just fetched.

It turns out that this unusual strictness on git's part is irritatingly inconvenient for me. I definitely don't want to actually commit my changes because that would contaminate what is otherwise a pure upstream repo history with a tangle of back and forth merges (even if I did it on a branch). There is 'git stash', but it has two aspects that I don't like; I have to remember (or be reminded) to do it explicitly and it makes changes to the repo itself (not just the checked-out files). I really like my repos to be exact, unchanged duplicates of the upstream.

(Yes, the changes 'git stash' makes should be harmless and should get fixed up when I do 'git stash clear' or the like. That's two 'shoulds'.)

This is a completely petty irritation (especially given 'git stash') and I fully acknowledge that. But I've never claimed to be entirely rational about this stuff and yes, it irritates me.

Sidebar: When this doesn't work in Mercurial

There is one circumstance when Mercurial will not do this sort of update at all, namely when the main branch in the repo shifts. The Mercurial repo for official Firefox releases hops branches this way when a new major release comes out and as a result I get to save a patch of my changes, overwrite them all by forcing a clean checkout, and then reapply them. Fortunately this is rare.

(Also these days I've found up switching to building my local Firefox from the main development repository, which doesn't branch this way.)

programming/GitAndLocalChanges written at 00:43:30; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.