4 ms·

What's the advantage to systemctl --host foo status httpd.service vs ssh -t foo systemctl status httpd.service ?

Aachen 10mo ago
Was wondering the same. "Do one thing and do it well" philosophy... If I want to run remote commands, I know how to do that already (namely, as you've shown), why learn to use a new tool for it? It's like these options to tar for compression: if I want to have a gzipped tar I'll run the tar c /sdcard output through |gzip thank you very much! (and drop in zstd instead)
mindcrime 10mo ago
> What's the advantage to ... For me personally, I'd say "not much". I'm used to using the latter form, and it's fine. But I will say that now that I know about this, I see using it in scenarios where I'm running a lot of systemctl commands over and over again in close proximity and have the "muscle memory" of typing "systemctl" more in mind. For example, when working with a new service that isn't quite working right yet, and doing many iterations of: $> systemctl start something.service $> systemctl status something.service $> journalctl -xeu something.service $> emacs whatever $> systemctl start something.service $> systemctl status something.service lather, rinse, repeat Especially if I'm testing on my laptop AND a remote deployment, I think it's easier from a cognitive viewpoint to always "think systemctl" instead of having to "think systemctl" sometimes and "think ssh systemctl" in others. To be fair though, it's all a pretty minor point. But I do think it's cool that systemctl has that option. shrug
- yjftsjthsd-h 10mo ago
  But that seems worse? If all your commands are systemctl, then you just have to ^p and edit/rerun, but there isn't a `systemctl $EDITOR /some/file`, so you'll have to ssh to run emacs (or use TRAMP, if using emacs), at which point you might as well just have a shell on the other end and do everything without having to tack --host onto your commands
  - mindcrime 10mo ago
    I don't know. Maybe. It seems like something that could be handy, but I don't yet know how much I'll wind up using it. For what it's worth, I was working on a scenario exactly like this earlier tonight, and I wound up just ssh'ing into a shell on the remote box to do stuff. But that might just be inertia from being used to doing that, or maybe it was because I had a lot of other stuff to do on that box at the same time...

Aachen 10mo ago

Was wondering the same. "Do one thing and do it well" philosophy... If I want to run remote commands, I know how to do that already (namely, as you've shown), why learn to use a new tool for it? It's like these options to tar for compression: if I want to have a gzipped tar I'll run the tar c /sdcard output through |gzip thank you very much! (and drop in zstd instead)

mindcrime 10mo ago

> What's the advantage to ... For me personally, I'd say "not much". I'm used to using the latter form, and it's fine. But I will say that now that I know about this, I see using it in scenarios where I'm running a lot of systemctl commands over and over again in close proximity and have the "muscle memory" of typing "systemctl" more in mind. For example, when working with a new service that isn't quite working right yet, and doing many iterations of: $> systemctl start something.service $> systemctl status something.service $> journalctl -xeu something.service $> emacs whatever $> systemctl start something.service $> systemctl status something.service lather, rinse, repeat Especially if I'm testing on my laptop AND a remote deployment, I think it's easier from a cognitive viewpoint to always "think systemctl" instead of having to "think systemctl" sometimes and "think ssh systemctl" in others. To be fair though, it's all a pretty minor point. But I do think it's cool that systemctl has that option. shrug

yjftsjthsd-h 10mo ago
But that seems worse? If all your commands are systemctl, then you just have to ^p and edit/rerun, but there isn't a `systemctl $EDITOR /some/file`, so you'll have to ssh to run emacs (or use TRAMP, if using emacs), at which point you might as well just have a shell on the other end and do everything without having to tack --host onto your commands
- mindcrime 10mo ago
  I don't know. Maybe. It seems like something that could be handy, but I don't yet know how much I'll wind up using it. For what it's worth, I was working on a scenario exactly like this earlier tonight, and I wound up just ssh'ing into a shell on the remote box to do stuff. But that might just be inertia from being used to doing that, or maybe it was because I had a lot of other stuff to do on that box at the same time...