2016-12-26
A perhaps surprising consequence of Requires dependencies in systemd
Oh right. This service restarted because I said 'Requires=rsyslog.service' & I updated rsyslogd (which restarted it). Moral: don't do that.
The systemd.unit manpage
tells you that this will happen if you read it carefully. In the
section on Requires:
If this unit gets activated, the units listed here will be activated as well. If one of the other units gets deactivated or its activation fails, this unit will be deactivated.
(Italics mine.)
When you or a package upgrade script does a 'systemctl restart
rsyslog', rsyslog is first deactivated, which triggers the
deactivation of my service, and then it is reactivated, which
fortunately results in the reactivation of my service too
(because systemd is not completely moronic, regardless of what
people may think of it).
The important thing to remember here is that Requires has two
effects. The first is that it forces the required unit to start on
boot (or activation of your unit) and will stop your unit from
starting if the required unit fails for some reason. So what I was
saying is 'my unit must have rsyslogd in order to start and work'.
The other, as we saw here, is that your unit will be deactivated
or restarted if its required unit fails or is restarted.
This restart behavior is not as crazy as it may sound. There are
services which are strongly linked and that don't recover transparently
from having their communication to a required service broken; one
traditional example is portmap.
In classical NFS, the various services that use SUNRPC registered
with portmap exactly once, when they started. If portmap was
restarted, those registrations were lost and could not be re-established
short of restarting all the other services too. This is a perfect
fit for a systemd Requires relationship.
(I believe this has been changed in modern SUNRPC code, for the obvious reason that it's kind of suboptimal.)
Unfortunately I don't believe that systemd has a form of requirement
that just does the initial boot time requirement stuff without the
'restart your service when a Requires restarts' bit. Wants is
not quite it because it doesn't stop your unit from starting if its
requirement doesn't. It's thus more useful for dependencies that
you would really like to be running but you don't absolutely totally
require.
Probably what I should do for this service is shift my requirement
over to the general syslog.socket, although that's not currently
activated on my system and I'm not completely sure it's the right
thing.
(It turns out that SUNRPC is now officially called ONC PRC, presumably because 'Sun' is a trademark and no one wanted to embed a trademark in the name of an official standard that was theoretically supposed to be vendor-neutral.)
Some new-to-me Vim motion commands that I want to try to remember
I've been trying to get better at vim on the grounds that I spend a bunch of time in it and even without caring about 'vim golf' there are a number of things about it that would save me time and effort. For now, my focus is on some additional movement commands and I'm primarily interested in text editing, not code (I do relatively little coding in vim for various reasons, but a lot of writing everything from documentation through email to Wandering Thoughts posts).
I already know a certain amount of the basic movement commands (or at least what I think of as basic movement commands), so I'm mining promising looking additional movement commands from the official documentation and other sources (including helpful comments here). In no particular order:
{ } |
I already use } a lot as part of reflowing
paragraphs with fmt and other tools, but for
various reasons I don't currently use these much
for pure movement. (Partly this is because I
don't entirely like how they put the cursor on
the blank line between paragraphs, which is
petty of me.) |
W |
This uses a definition of 'word' that's usually more how I think about words in text. I should make use of it both for movement and for deletion and changes. |
( ) |
I often work on things with sentences so by-sentence movement should be useful. |
b B |
Backing up by words is faster than by characters. Of course backing up by sentences is even faster. |
e E |
Moving forward to the end of a word instead of the start is convenient for setting up edits. |
f |
I'm most likely to use this inclusive version of
t when editing a text run, because often I'm
editing up to and including its closing character. |
F T |
These are questionable; I want to say I have real uses for going backwards to characters, but I'm not sure I do. They also only operate on the current line, making them less useful for large jumps (but more controllable for edits). |
I'm not sure if I have much use for the a[Ww] and i[Ww] text
object selectors. They sound cool in the abstract but I believe
that most of the time I'm modifying text I'm at the start (or end)
of the word I want to cover. At least right now my gut feels that
it's not worth trying to remember, use, and practice them on top
of the others in this list.
(An honorable mention goes to # and *, find previous/next
occurrence of the word under the cursor. They sound neat and I
sort of think I have uses for them, but probably not really.)
I should also probably focus purely on W, B, and E, which
means not even trying to practice b and e. I already know w,
so that's sticking around, but I should try to use it less. Of
course, the w, b, and e versions are tempting since they're
slightly easier as lower case and almost always do what I want.
(I have no interest in shifting my text reflowing reflexes to use
vim's native gq operation. !}fmt is such a reflex by now that
I actively have to think about what the sequence actually is, and
it's more flexible in various ways for me. In theory I should
probably think about using !apfmt to not have to jump to the start
of the paragraph first, but I'm not sure I like it or want to try
to remember it now. It also has the side effect of moving my cursor
position to the start of the paragraph.)
The other bit of vim that I should use more actively than I do right
now is deleting and pasting words to move them around in my text. For
no particularly great reason, I always think about vim's deletion and
pasting as being line-based, while in at least modern vim it's perfectly
capable of being used to shuffle phrases around within a line and the
like. It's possible that moving to a less line-oriented view of moving
text around could make the as text object more useful to me, if I want
to use it as part of re-ordering or deleting sentences.
If I'm using these new motion operations to select text ranges for
editing operations instead of moving around, I might want to use
v to enter visual (selection) mode. This would give me the chance
to see exactly what I'm selecting before I fire off an editing
operation on it, which might increase my confidence and make me
more likely to use these new things.
PS: this article has an interesting wallpaper of a bunch of movement commands.
Sidebar: Window commands I want to remember
The quick reference is here, the longer reference here. I read all of this once and parts of it failed to stick, so hopefully I can do better this time around.
| Ctrl-W j/k | Move to window up/down (also the cursor keys) |
:split <file> |
Split window to a new file |
| Ctrl-W c | Close current window |
| Ctrl-W o | Current window becomes only window |
| Ctrl-W s | Split window |
| Ctrl-W +/- | Increase/decrease current window size. |
:q will quit editing a file and close the current window on it, but
:qall is what I really want at the end of a multi-file editing session
because it closes everything down at once.
(Windows and multi-file operations are one of my big vim blind spots and thus one area where more mastery could really help.)