12 ms·

This looks neat. I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right,

by owyn 2y ago

This looks neat. I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right, sudo systemctl start service.foo And the feedback is so bad. It should know everything in its own config dir and tell me how to do what I want to do. Was it enabled? I forget. How do I look at logs? Oh right journalctl. Also the layout of things with lots of symlinks and weird directories in places that annoy my 90's linux sysadmin brain. Why am I looking at /lib/systemd/system I am annoyed by the redundant "systemd/system" directory name every time I have to go there. At this point, just promote it to /etc/systemd and build a better CLI. As a very occasional linux sysadmin just trying to make things work, the "typing at a console" systemd interfaces are not fun to work with. Maybe nobody should be doing that. In an enterprise, sure that's different. I think interfaces should be human, and linux should still be fun.

mixmastamyk 2y ago
I haven’t had much trouble with the cli, but it is kinda wordy. I made this alias: alias sc='sudo systemctl' Now it matches the sc utility introduced in Windows many years back. Then remember the verb goes first.
- johnisgood 2y ago
  Yeah, and you can omit the ".service" suffix, and you could use ".timer" suffix, too, if you have a timer for that service. As much as I do not like systemd, I do not think its commands are an issue, and I use "systemctl status" and "journalctl" as well with some flags at times.
  - robinsonb5 2y ago
    "systemctl" would be less of an issue if "sysctl" didn't already exist and do something completely different.
    - johnisgood 2y ago
      Yes, it is something I had to learn in the very beginning, but I never made the mistake ever again.
kjkjadksj 2y ago
It is a bit crazy to me how everyone says “dont use cron systemd is in now” but cron just does what it says on the tin with no problems. I have lines that work fine ran in script or on my crontab but when wrapped in a launchd command no longer work (log says things work until the db is to be updated which tells me launchd ran processes lack sufficient permissions perhaps to update my db but its not clear why this is the case or how I can elevate launchd sufficiently.
- viraptor 2y ago
  Launchd is not used in systemd - why would anything be wrapped in it? The config is simple - User for the user and Group for the group. You can print it the result of "id" if you're not sure what the result is.
  - kjkjadksj 2y ago
    Sorry I conflate the two since they share a lot of similarity. Launchd is what I use as its a macos system.
- MrDrMcCoy 2y ago
  > cron just does what it says on the tin with no problems. I can name a rather large problem with cron that systemd timers solve handily: long-running job duplication. When jobs take longer to run than the space between their triggering times, duplicates start piling up. I've had to rescue numerous systems from such states, which are difficult to detect until things have gotten quite bad. Sure, you can write a bunch of boilerplate to handle this yourself with cron, but with systemd timers it's all handled for you along with other niceties like capturing all output in journald and ensuring that the next run starts at soon as possible.
- simoncion 2y ago
  > ...cron just does what it says on the tin with no problems. Yeah, tell me about it. We had a production-down support ticket filed for one of the things that I work on at $DAYJOB. The customer's VM's disk was full. Why? Because the 'timer unit' that was supposed to run logrotate every day had never been run and was never scheduled to run. (The VM had been up for a month at this point.) No other customers had ever reported this issue, and we'd not changed anything about that timer unit or what it is supposed to run in ages. No amount of gyration or agitation with 'systemctl' and friends OR rebooting of the VM kicked the cron replacement into proper functioning. 'logrotate' was simply never being scheduled to run. This fucker was WEDGED, and the tools weren't helping us understand why. We read through all the docs on all the various kinds of units and don't see what we're doing wrong. We do a BUNCH of digging, and find an -IIRC- open Github issue from years back where someone was running into this problem. More or less the last word on the issue was Poettering saying something like "Well... actually, now that we've said that that particular cascade of options isn't actually supposed to work, now I'm not so sure that they're NOT supposed to work.". And that was -apparently- that. IMO, when your cron replacement can be easily configured in such a way as to never even try to run the thing that you scheduled it to run, you really need to go back and rethink how you've built your cron replacement.
Denvercoder9 2y ago
> I am annoyed by the redundant "systemd/system" directory name It's not redundant, you also have /etc/systemd/user (and /lib/systemd/user) where units that run in the user context (as opposed to system-wide context) are stored.
- godelski 2y ago
  It's also worth noting that this is a fairly standard pattern in /etc / | etc | | fail2ban | | | action.d | | | fail2band.d | | | filter.d | | | jail.d | | ssh | | | ssh_config | | | sshd_config | | systemd | | | network # network wide context | | | nspawn # containers | | | system # system wide context | | | user # user wide context Personally I like it more than / | etc | | cron.d | | cron.daily | | cron.hourly | | cron.monthly | | cron.weekly | | ... | | firewall | | firewalld Keeps things less cluttered. Hierarchical categorization is >> than lateral
- cyberax 2y ago
  It could have been named 'global' instead of 'system'.
rcxdude 2y ago
I find that at least systemd means that it's consistent across distros. I spent way more time looking up this kind of thing when every distro rolled their own init system.
greenavocado 2y ago
This is why I have instated a policy of using systemd --user services whenever possible. If you don't need elevated permissions this is ideal. All you have to do is enable linger using loginctl if you want your service to auto start as the user on boot unattended. Your user services live in ~/.config/systemd/user
- bityard 2y ago
  I used to do this but frankly it's easier to run a system-level unit as whatever user you want and keep all the files in /etc instead of scattered around /home. The user-level units are most useful when running an actual multi-user system. If you trust your users to not abuse them, anyway.
- j16sdiz 2y ago
  I tried, but found it very confusing around the user session. Apparently an environment variable need to point to a started dbus. I can't get consistent results over local session vs ssh vs su vs sudo
  - greenavocado 2y ago
    What are you trying to do with dbus?
zamadatix 2y ago
My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but never enough of the service's log to get a useful picture of what's actually happened with the service lately. Not to mention unless the problem with the service completely prevented it from running (it advises some commands to run in that case) you're supposed to just always remember "journalctl -xeu $SERVICE" was the incantation, less you want to go look up the flags again or manually parse the entire "journalctl" output. Overall I generally like systemd though. The syntax can just be a burden sometimes.
- Denvercoder9 2y ago
  In case you don't know, you can use the `-n` argument to `systemctl status` to tweak the log output, e.g. `-n0` to disable the log output and `-n40` to get more than the default 10 lines.
  - zamadatix 2y ago
    That's a great option to tweak the behavior and I hadn't known about it (or if I ever had, I'd well forgotten). Thanks! From the man page it ?looks like? if you want reverse or full then it's still off to the journalctl command and arguments but at least "-n9999" is better than "always 10 lines".
    - godelski 2y ago
      FWIW, I don't want that behavior. 10 lines is great for my usage. And IIRC you can change the default behavior. In the worst case, just alias it if it is bothering you that much.
      - zamadatix 2y ago
        Glad you like it! I'd rather learn to deal/work with the rough spots than stick my head in the sand with an alias and be even more lost when I don't have it or am working with someone else though. At least for the super common tools like git, systemctl, grep, and the like.
pkkm 2y ago
> I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right, sudo systemctl start service.foo I don't get this complaint. It's the same order as almost every other command-line utility that has subcommands: <command> <subcommand> <thing to operate on>. To me, that kind of consistency is very intuitive. systemctl stop my-service systemctl status my-service git add my-file git remote remove upstream apt install my-package docker run my-container adb push local-file remote-file
- kstrauser 2y ago
  For me: * /etc/init.d/my-service stop and Ubuntu’s: * service my-service stop both lurk in my brain.
  - pkkm 2y ago
    Sure, it's different from the old way, but I don't think "unintuitive" is the right word for that. systemd forced people to change their habits so that it could be more intuitive. Of course, people are going to disagree about whether it was worth it - it's the age-old question about breaking backwards compatibility for the sake of minor improvement. Personally, I got used to it pretty quickly and I like it more than the old commands now.
    - b112 2y ago
      Yet, the "ease" of use is a joke. Every try to stop and start a service at different points? At points you choose? Have fun! Ah well, it's all been said before.
    - kstrauser 2y ago
      Yeah, I gave up resisting and I’m rolling with it. Ok, fine, this is the way now. And yet my fingers still want to type it the other way.
    - ndom91 2y ago
      The way I remember this is that the old way didn't allow for applying the verb to multiple units. Now you can "restart" multiple units, i.e. `systemctl restart nginx webapp`, etc.
PhilipRoman 2y ago
I just wish systemd allowed abbreviations for the subcommands, like "ip" (and git, for long options).
kai-tub 2y ago
Author here: Yeah, I agree. It is a bit weird. On the one hand, I understand that it makes sense to have [command] [verb] [object] on a "logical" level and that viewing logs should be a separate command (`journalctl`), but it is definitely not ergonomic. Especially if you frequently have to switch between start/stop/restart. > As a very occasional linux sysadmin just trying to make things work, the "typing at a console" systemd interfaces are not fun to work with. Maybe nobody should be doing that. In an enterprise, sure that's different. I think interfaces should be human, and linux should still be fun. This was precisely the case for me. I "enjoy" playing around with systemd and am super interested in better understanding it, but the feedback loop just felt sooo slow. So hopefully this TUI can make it "fun" again :)
- BenjiWiebe 2y ago
  When I'm really working with a service and get tired of typing sudo systemctl restart or status all the time, I'll just do a quick alias or two right then and there. alias s=sudo systemctl status alias r=sudo systemctl restart And if I'm only working with one service, I'll throw the service name in there too.
BrouteMinou 2y ago
I am going to be that guy, but I went full runit for similar reasons. Give me files for my logs, give me a single place for my service definitions, be simple. After years of systemd, I have never really "got it", while it took a weekend for runit. It's not always our choice, corporate world is something else, I know...
SoftTalker 2y ago
By the time you have it all memorized, they'll change it. Again. Because... because.
noumuon 2y ago
Fiddly and unintuitive? A lack of exposure to something does not really allow room for valid criticism of the thing. Just a tip, if you remember the service name, status will show the directory the unit file is in. That will hopefully get you over your issues with directories. Complaining about Linux directories seems weird though. Have you looked at... anything else at all?
deleted 2y ago
[deleted]

by owyn 2y ago

mixmastamyk 2y ago

I haven’t had much trouble with the cli, but it is kinda wordy. I made this alias: alias sc='sudo systemctl' Now it matches the sc utility introduced in Windows many years back. Then remember the verb goes first.

johnisgood 2y ago
Yeah, and you can omit the ".service" suffix, and you could use ".timer" suffix, too, if you have a timer for that service. As much as I do not like systemd, I do not think its commands are an issue, and I use "systemctl status" and "journalctl" as well with some flags at times.
- robinsonb5 2y ago
  "systemctl" would be less of an issue if "sysctl" didn't already exist and do something completely different.
  - johnisgood 2y ago
    Yes, it is something I had to learn in the very beginning, but I never made the mistake ever again.

kjkjadksj 2y ago

It is a bit crazy to me how everyone says “dont use cron systemd is in now” but cron just does what it says on the tin with no problems. I have lines that work fine ran in script or on my crontab but when wrapped in a launchd command no longer work (log says things work until the db is to be updated which tells me launchd ran processes lack sufficient permissions perhaps to update my db but its not clear why this is the case or how I can elevate launchd sufficiently.

viraptor 2y ago
Launchd is not used in systemd - why would anything be wrapped in it? The config is simple - User for the user and Group for the group. You can print it the result of "id" if you're not sure what the result is.
- kjkjadksj 2y ago
  Sorry I conflate the two since they share a lot of similarity. Launchd is what I use as its a macos system.
MrDrMcCoy 2y ago
> cron just does what it says on the tin with no problems. I can name a rather large problem with cron that systemd timers solve handily: long-running job duplication. When jobs take longer to run than the space between their triggering times, duplicates start piling up. I've had to rescue numerous systems from such states, which are difficult to detect until things have gotten quite bad. Sure, you can write a bunch of boilerplate to handle this yourself with cron, but with systemd timers it's all handled for you along with other niceties like capturing all output in journald and ensuring that the next run starts at soon as possible.
simoncion 2y ago
> ...cron just does what it says on the tin with no problems. Yeah, tell me about it. We had a production-down support ticket filed for one of the things that I work on at $DAYJOB. The customer's VM's disk was full. Why? Because the 'timer unit' that was supposed to run logrotate every day had never been run and was never scheduled to run. (The VM had been up for a month at this point.) No other customers had ever reported this issue, and we'd not changed anything about that timer unit or what it is supposed to run in ages. No amount of gyration or agitation with 'systemctl' and friends OR rebooting of the VM kicked the cron replacement into proper functioning. 'logrotate' was simply never being scheduled to run. This fucker was WEDGED, and the tools weren't helping us understand why. We read through all the docs on all the various kinds of units and don't see what we're doing wrong. We do a BUNCH of digging, and find an -IIRC- open Github issue from years back where someone was running into this problem. More or less the last word on the issue was Poettering saying something like "Well... actually, now that we've said that that particular cascade of options isn't actually supposed to work, now I'm not so sure that they're NOT supposed to work.". And that was -apparently- that. IMO, when your cron replacement can be easily configured in such a way as to never even try to run the thing that you scheduled it to run, you really need to go back and rethink how you've built your cron replacement.

Denvercoder9 2y ago

> I am annoyed by the redundant "systemd/system" directory name It's not redundant, you also have /etc/systemd/user (and /lib/systemd/user) where units that run in the user context (as opposed to system-wide context) are stored.

godelski 2y ago
It's also worth noting that this is a fairly standard pattern in /etc / | etc | | fail2ban | | | action.d | | | fail2band.d | | | filter.d | | | jail.d | | ssh | | | ssh_config | | | sshd_config | | systemd | | | network # network wide context | | | nspawn # containers | | | system # system wide context | | | user # user wide context Personally I like it more than / | etc | | cron.d | | cron.daily | | cron.hourly | | cron.monthly | | cron.weekly | | ... | | firewall | | firewalld Keeps things less cluttered. Hierarchical categorization is >> than lateral
cyberax 2y ago
It could have been named 'global' instead of 'system'.

rcxdude 2y ago

I find that at least systemd means that it's consistent across distros. I spent way more time looking up this kind of thing when every distro rolled their own init system.

greenavocado 2y ago

This is why I have instated a policy of using systemd --user services whenever possible. If you don't need elevated permissions this is ideal. All you have to do is enable linger using loginctl if you want your service to auto start as the user on boot unattended. Your user services live in ~/.config/systemd/user

bityard 2y ago
I used to do this but frankly it's easier to run a system-level unit as whatever user you want and keep all the files in /etc instead of scattered around /home. The user-level units are most useful when running an actual multi-user system. If you trust your users to not abuse them, anyway.
j16sdiz 2y ago
I tried, but found it very confusing around the user session. Apparently an environment variable need to point to a started dbus. I can't get consistent results over local session vs ssh vs su vs sudo
- greenavocado 2y ago
  What are you trying to do with dbus?

zamadatix 2y ago

My biggest annoyance is "systemctl status" gives you just enough of the service's log to make the output take up most of the terminal each time you run it but never enough of the service's log to get a useful picture of what's actually happened with the service lately. Not to mention unless the problem with the service completely prevented it from running (it advises some commands to run in that case) you're supposed to just always remember "journalctl -xeu $SERVICE" was the incantation, less you want to go look up the flags again or manually parse the entire "journalctl" output. Overall I generally like systemd though. The syntax can just be a burden sometimes.

Denvercoder9 2y ago
In case you don't know, you can use the `-n` argument to `systemctl status` to tweak the log output, e.g. `-n0` to disable the log output and `-n40` to get more than the default 10 lines.
- zamadatix 2y ago
  That's a great option to tweak the behavior and I hadn't known about it (or if I ever had, I'd well forgotten). Thanks! From the man page it ?looks like? if you want reverse or full then it's still off to the journalctl command and arguments but at least "-n9999" is better than "always 10 lines".
  - godelski 2y ago
    FWIW, I don't want that behavior. 10 lines is great for my usage. And IIRC you can change the default behavior. In the worst case, just alias it if it is bothering you that much.
    - zamadatix 2y ago
      Glad you like it! I'd rather learn to deal/work with the rough spots than stick my head in the sand with an alias and be even more lost when I don't have it or am working with someone else though. At least for the super common tools like git, systemctl, grep, and the like.

pkkm 2y ago

> I have to look up the very fiddly and unintuitive systemd commands all the time. service start? service.foo start? start foo.service? Oh right, sudo systemctl start service.foo I don't get this complaint. It's the same order as almost every other command-line utility that has subcommands: <command> <subcommand> <thing to operate on>. To me, that kind of consistency is very intuitive. systemctl stop my-service systemctl status my-service git add my-file git remote remove upstream apt install my-package docker run my-container adb push local-file remote-file

kstrauser 2y ago
For me: * /etc/init.d/my-service stop and Ubuntu’s: * service my-service stop both lurk in my brain.
- pkkm 2y ago
  Sure, it's different from the old way, but I don't think "unintuitive" is the right word for that. systemd forced people to change their habits so that it could be more intuitive. Of course, people are going to disagree about whether it was worth it - it's the age-old question about breaking backwards compatibility for the sake of minor improvement. Personally, I got used to it pretty quickly and I like it more than the old commands now.
  - b112 2y ago
    Yet, the "ease" of use is a joke. Every try to stop and start a service at different points? At points you choose? Have fun! Ah well, it's all been said before.
  - kstrauser 2y ago
    Yeah, I gave up resisting and I’m rolling with it. Ok, fine, this is the way now. And yet my fingers still want to type it the other way.
  - ndom91 2y ago
    The way I remember this is that the old way didn't allow for applying the verb to multiple units. Now you can "restart" multiple units, i.e. `systemctl restart nginx webapp`, etc.

PhilipRoman 2y ago

I just wish systemd allowed abbreviations for the subcommands, like "ip" (and git, for long options).

kai-tub 2y ago

Author here: Yeah, I agree. It is a bit weird. On the one hand, I understand that it makes sense to have [command] [verb] [object] on a "logical" level and that viewing logs should be a separate command (`journalctl`), but it is definitely not ergonomic. Especially if you frequently have to switch between start/stop/restart. > As a very occasional linux sysadmin just trying to make things work, the "typing at a console" systemd interfaces are not fun to work with. Maybe nobody should be doing that. In an enterprise, sure that's different. I think interfaces should be human, and linux should still be fun. This was precisely the case for me. I "enjoy" playing around with systemd and am super interested in better understanding it, but the feedback loop just felt sooo slow. So hopefully this TUI can make it "fun" again :)

BenjiWiebe 2y ago
When I'm really working with a service and get tired of typing sudo systemctl restart or status all the time, I'll just do a quick alias or two right then and there. alias s=sudo systemctl status alias r=sudo systemctl restart And if I'm only working with one service, I'll throw the service name in there too.

BrouteMinou 2y ago

I am going to be that guy, but I went full runit for similar reasons. Give me files for my logs, give me a single place for my service definitions, be simple. After years of systemd, I have never really "got it", while it took a weekend for runit. It's not always our choice, corporate world is something else, I know...

SoftTalker 2y ago

By the time you have it all memorized, they'll change it. Again. Because... because.

noumuon 2y ago

Fiddly and unintuitive? A lack of exposure to something does not really allow room for valid criticism of the thing. Just a tip, if you remember the service name, status will show the directory the unit file is in. That will hopefully get you over your issues with directories. Complaining about Linux directories seems weird though. Have you looked at... anything else at all?

deleted 2y ago

[deleted]