Most active commenters
  • Brian_K_White(3)
  • robertlagrant(3)

←back to thread

466 points CoolCold | 12 comments | | HN request time: 0.002s | source | bottom
Show context
kbar13 ◴[] No.40208219[source]
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run globally to the front of the filename". it's provided an extensible platform with which higher level orchestration frameworks like ansible / ignition can easily templatize services or other system configuration.

since the beginning of systemd people have moaned about how complex it is and how we're reinventing the wheel. yet time and time again the people actually working on the project show that the solution they've come up with is the result of the problem they're facing on a daily basis. it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back", maybe think about whether or not you have a legitimate issue not being addressed by the solution proposed or if you are just getting rage baited by a headline.

replies(17): >>40208249 #>>40208286 #>>40208374 #>>40208481 #>>40209110 #>>40209185 #>>40212620 #>>40212965 #>>40214704 #>>40214800 #>>40214923 #>>40215163 #>>40215552 #>>40215793 #>>40216445 #>>40217144 #>>40217617 #
agilob ◴[] No.40214923[source]
> remember when you had to write bash scripts to start, stop, restart services

This was a really big pain, yes, but I also remember how I could `tail -f *.logs`. I remember how I didn't need to remember about `--no-pager` and `--follow`. I knew where the files were, what they were called. I remember how I didn't have to google how to find logs between 10 days ago and 4 days ago, because the logs would be in a .tar created by logrotate with a date in the filename.

The init system was probably peak of systemd, after that they started reinveting things in a more complicated way. Do we really need journald, systemd-boot, machinectl, systemd-networkd, sd-bus, systemd-resolved, systemd-nspawn? Do people actually use it all? Are there any metrics to show how many systems have it installed and in use?

replies(8): >>40215028 #>>40215089 #>>40215154 #>>40215742 #>>40216065 #>>40216893 #>>40217407 #>>40218927 #
superb_dev ◴[] No.40215028[source]
The follow argument is identical to tail `-f`. `sudo journalctl -f -u <service name>`
replies(2): >>40215268 #>>40215896 #
rangerelf ◴[] No.40215268[source]
And what would be the equivalent to, "Oh, I don´t know the name of the log for this process I can see in 'ps aux', let me cd into /var/log and see what filenames I can find ... or grep everything until I can find a couple of words that make some sense so I can keep digging further"?

The lack of explorability in journalctl, the "need" to keep everything locked behind their own flavor of tools and magic file types, is what makes the rest of us abhor them.

replies(6): >>40215373 #>>40215724 #>>40215825 #>>40216093 #>>40216232 #>>40217449 #
1. ciupicri ◴[] No.40215825[source]

    # journalctl -f _PID=${your_pid}  # option 1
    # systemctl status ${your_pid}    # option 2
[1]: https://www.freedesktop.org/software/systemd/man/latest/jour...

[2]: https://www.freedesktop.org/software/systemd/man/latest/syst...

replies(1): >>40216104 #
2. Brian_K_White ◴[] No.40216104[source]
These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem.

The problem with systemnd is it assumes that it's possible for all needs to be predicted and accounted for ahead of time. While "look around at directories and files, and grep within them" works after the fact without any special knowledge or tools. The person who wrote the log file did not need to know how someone will maybe try to access it 23 years later on a different OS. It's just a regular file that can be read by anything over any kind of channel on any os. The person finding themselves needing to read the file does not need to have any particular command installed, or installable, or runnable. It does not require the happy path in order to work.

I have a joke I always say, often self-deprecating making fun of my own self for the way I do things sometimes, but also when I'm trying to commiserate with a customer so they don't feel intimidated by "the expert" or "the engineer": "37 easy steps!"

Every answer that starts with "it's simple, just journalctl ..." is FUCKING 37 easy steps. The very name of the program itself is a trainwreck. journalctl... it takes me 18 seconds just to type it.

systemd is great for managing exquisitely washed masses of drone vms. It's utter and complete shit for direct administration, operation, development, debugging, flexibility, or custom integrations.

replies(5): >>40216624 #>>40217591 #>>40219141 #>>40221003 #>>40256621 #
3. robertlagrant ◴[] No.40216624[source]
> These absolutely SUCK as answers to that question. They entirely miss the point. They provide a specific answer to a general problem.

No they don't. They are good answers. If you want answers to a more general problem, then ask. This is not an emotive topic.

replies(1): >>40216759 #
4. Brian_K_White ◴[] No.40216759{3}[source]
They may be correct answers, in that they accomplish a task.

They suck in that the proposed method for accomplishing the task is a suck-ass downgrade from the previous ways the new way proposes to displace.

I beg to differ about emotive, because absolutely the other side of this fence behaves every bit as butt-hurt when challenged as I just did. You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive.

replies(2): >>40216862 #>>40218443 #
5. robertlagrant ◴[] No.40216862{4}[source]
> You yourself just said these crappy commands were good, as a purely unfounded assertion. They are great because you just say they are great. That is even less objective than my rant. I at least explained what exactly I find so bad. Tell me more about not emotive.

Very well: I didn't say the commands were good or great. If you attempt a little objectivity you'll see it.

replies(1): >>40217125 #
6. Brian_K_White ◴[] No.40217125{5}[source]
If you attempt a little objectivity, you will see that addressing the answers (vs the commands) was in my first response.

Before even going into the nature of the commands, I said that the answer does not match the question. The answers addressed details, while the details in the question were merely examples.

Missing the point is actually merely one of the at least two dimensions along which the answers suck. Thank you for reminding me about that.

replies(1): >>40217435 #
7. robertlagrant ◴[] No.40217435{6}[source]
> The answers addressed details, while the details in the question were merely examples.

No, the answers addressed the two scenarios in the question. That's why they don't "SUCK". They are good answers to the question as asked, and not the question as you dreamed it. If you spent ten words on asking the question of your dreams, rather than having a go at people for not answering it (whatever it is), you might have an answer.

8. sgarland ◴[] No.40217591[source]
Agreed. I’ve tried to get used to it on Debian 12 for personal VMs. I just can’t. I don’t care. grep and awk are always going to be available, and I know how to use them.
9. sunshowers ◴[] No.40218443{4}[source]
To be clear -- you can just dump out all the logs to text and then use your standard grep toolkit on them. You can also dump them out to JSON, and use jq on them -- something you can't do with text logs on disk.

And as far as learning the options goes, learning the basics of systemd and journalctl is much easier than learning how to, say, use a source control system effectively.

(And it's definitely worth trying out new source control systems -- for example, I think most people should at least check out Jujutsu, and many people are going to like it more than Git. As simple as Jujutsu is to use, learning it takes a lot longer than learning journalctl.)

10. superb_dev ◴[] No.40219141[source]
I didn’t answer the general question because I don’t care, I have no dog in this fight. Im just happy to provide information.

I like systemd and have found it extremely useful. If it doesn’t fill a need for you then use something else.

11. rcxdude ◴[] No.40221003[source]
It's way better than the previous status quo: now, more or less whatever distro I'm on, there's one command which answers that question directly, not a process of guessing how this system happens to be set up. You can guess and grep through most any kind of problem, but I don't see why anyone would want to do it as anything but a last resort, and to me that fits '37 easy steps' far more than the 1 consistent step in these replies (notice how none of them say 'oh, but on debian...'?).
12. throwaway7356 ◴[] No.40256621[source]
> journalctl... it takes me 18 seconds just to type it.

Sounds like you don't use a keyboard often enough to even remember where the keys are. Not sure I would expect deep (or even shallow) knowledge on UNIX system administration from such a person.