4 ms·
These are fine points, and there are rough edges, but: 1. `systemctl status nginx.service` suffices in many cases. journalctl is for when you need to dig deepe
by e-khadem 1y ago
These are fine points, and there are rough edges, but:
1. `systemctl status nginx.service` suffices in many cases. journalctl is for when you need to dig deeper, and it demands many more options. You would have complained about "too noisy CLI arguments" if these were unified.
2. I am not sure about how I should parse this. You mean there are too many arguments in total (2a) or the man page or the help message is not ordered correctly (2b)?
(2a). If you just care about services, you already know [well] a handful of subcommands (start, stop, enable, etc.) and just use those, the other args don't get in your way. For example your everyday commands have safe, sane default options that you will not have to override 99% of the time.
Furthermore, this is much better than the alternative of having a dozen different utilities that have a non-trivial inter-utility interaction that has to be solved externally. Sometimes an application that does (just) one thing won't do well.
(2b). This is subjective (?). I have experienced a few week-long total internet outages (in Iran). I had to study the man pages and my offline resources in those contingencies, and have generally been (extremely) satisfied with the breadth, depth, and the organization of the systems docs. In the age of LLMs this is much less of a problem anyways. I think reading the man page of a well-known utility is not an everyday task, and for a one-off case you will grep the man page anyways.
3. Your point is ~valid. But automount exists for ephermal resources. By default, we won't touch a failing drive without some precautions at least. So fail-fast and no retry is not always wrong. Perhaps it is virtue signaling ... On my PC I don't want to retry anything if a mount fails. In fact I might even want it to fail to boot so that it doesn't go undetected.
Also, for something as critical as mounting, I would probably want other "smart" behavior as well (exponential backoff for network, email, alert, DB fail-over, etc.) and these require specific application knowledge.
So ... they are trying to prevent a foot gun.
- darkwater 1y ago> 1. `systemctl status nginx.service` suffices in many cases. journalctl is for when you need to dig deeper, and it demands many more options. You would have complained about "too noisy CLI arguments" if these were unified. I'm not at all a systemd hater (I think it was needed and it's nowadays a very solid piece of software) but the logs thing should be totally tweakable when viewing it from `systemctl status` and it is n.... [goes to check the man page] -n, --lines= When used with status, controls the number of journal lines to show, counting from the most recent ones. Takes a positive integer argument, or 0 to disable journal output. Defaults to 10. Oooh, so TIL.
- kstrauser 1y agoOMG, TIL, too. This made my morning.
- VagabundoP 1y agoAs always RTFM applies - or at least glance through it at high speed.
- atoav 1y agoI parsed (2) in the obvious way of: A manual should start with the common stuff 99% of people need and not with something obscure that you will only need once you are at the level that you know the tool you're using inside out. That is like opening the manual for your dishwasher and reading a section about how you may check the control-boards conformal coating after the warranty has expired. Useful when you need it and have the repair skills, but a bad way to start a manual.
- skydhash 1y agoThat’s a tutorial or a getting started guide. The manual is a memory helper, like a tiny encyclopedia, not a teaching material.
- SSLy 1y agotutorial vs reference https://diataxis.fr/ https://diataxis.fr/
- atoav 1y agoHow does that change my point about an order by frequency of use being superior? If it is a memory helper, then the stuff people tend to use more often is certainly the stuff that needs to be looked up more.
- skydhash 1y agoThat’s a variable order. I prefer a more consistent order like a default section structure (which a lot of man pages adopt) and an alphabetical order for flags (which a lot of man pages also adopt). When I open a manual it’s usually for: flags and argument ordering; argument format (for things like string format or globbing). Some manuals are short enough that it can serve as a guide, but most assumes domain knowledge. What you want is a cheatsheet. And there’s a lot on the internet and even some tools that collect them. But most practitioners write shell aliases and functions
- atoav 1y ago
- cyberax 1y ago1. systemctl already supports logging output, and it's already overloaded. 2. The options are not filtered, so useful options like ('--lines') are lost. E.g. what other options apply to "systemctl status"? The systemd documentation, in general, is a mess. It's a good _reference_ documentation (like 'man') but not a good guide. 3. Network filesystems exist. And they can become unavailable for a time.
- e-khadem 1y ago> 3. Network filesystems exist. And they can become unavailable for a time. See [1] > the same applies to remote file system mounts. If you want them to be mounted only upon access, you will need to use the x-systemd.automount parameters. In addition, you can use the x-systemd.mount-timeout= option to specify how long systemd should wait for the mount command to finish. Also, the _netdev option ensures systemd understands that the mount is network dependent and order it after the network is online. > You may also specify an idle timeout for a mount with the x-systemd.idle-timeout flag. [1] https://wiki.archlinux.org/title/Fstab#Automount_with_systemd https://wiki.archlinux.org/title/Fstab#Automount_with_system...
- cyberax 1y ago> Note that this option can only be used in /etc/fstab, and will be ignored when part of the Options= setting in a unit file. What did I say about consistency (or more precisely, the lack thereof)?