6 ms·

The follow argument is identical to tail `-f`. `sudo journalctl -f -u <service name>`

rangerelf 2y ago
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.
- iforgotpassword 2y ago
  Huh, isn't grepping journalctl output pretty much the same? It even prefixes messages by the binary name.
  - mdaniel 2y ago
    Pedantically, they're the unit name which only sometimes matches the binary name
    - rezonant 2y ago
      Actually no, they are prefixed by the binary name and the PID number. Technically they are prefixed with: `<date> <host> <binary>[<pid>]`. You can then use `systemctl status <pid>` to identify the unit if you need to. I would imagine this is configurable, and this might be the configuration chosen by my distribution (since I have not changed it myself). It would actually be nice to show the unit name instead of the binary/PID combination, though not strictly necessary. EDIT: Ooh, systemd 239 adds `journalctl -o with-unit` to do this exact thing. There are lots of other formats you can choose from as well. EDIT 2: Unfortunately there's no way to set this as default, you must use `-o with-unit` each time or set up a shell alias :-\
- superb_dev 2y ago
  Well `-u` refers to the unit file, so I would start with `sudo systemctl status` which lists the status of active unit files. I bet I could find the unit name I'm looking for there. If not, then `sudo systemctl list-units` should have it. (and you can grep the output of both) Systemd and Journald are less opaque than I used to think. Even if you don't want to learn the commands, all of its unit files (and the relationships between them) are available through the filesystem. Most of your unit files will be in `/etc/systemd/system`, and the active relationships between units are expressed through soft links.
  - aeonik 2y ago
    How would you exclude certain units from your logs? Let's say that Auditd is spamming your logs, and you just want to exclude those? Can you filter on search? How do you prevent applications from writing to Systemd at all?
    - superb_dev 2y ago
      I would start with `man systemd`, or maybe `journalctl —help`. If you don’t want a service to log to systemd, then don’t run it in systemd?
      - pcthrowaway 2y ago
        I think you can also configure the journal per unit right? Don't remember how exactly, at the very least you can stream logs to a different system. There are also services which will just use their own logging convention for some reason. Honestly it's easier just to go with journalctl for everything you can.
  - ramses0 2y ago
    systemctl does not have the Unix nature.
- ciupicri 2y ago
  # journalctl -f _PID=${your_pid} # option 1 # systemctl status ${your_pid} # option 2 [1]: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html#Examples https://www.freedesktop.org/software/systemd/man/latest/jour... [2]: https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#status%20PATTERN%E2%80%A6%7CPID%E2%80%A6%5D https://www.freedesktop.org/software/systemd/man/latest/syst...
  - Brian_K_White 2y ago
    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.
    - throwaway7356 2y ago
      > 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.
    - robertlagrant 2y ago
- sunshowers 2y ago
  You do have to learn a few new things, yes. But it's not too difficult. We all have to learn new things sometimes. I spent around 15 minutes a few weeks ago learning how to do a few things with journalctl, and I came away from it with a great appreciation for its power.
- rcxdude 2y ago
  systemctl status <pid> will show you the unit and helpfully the last few lines of log from it. Journalctl -u <unit name> will then show you the full logs
- JoshTriplett 2y ago
  > Oh, I don´t know the name of the log for this process I can see in 'ps aux', With services using journald, there's no "name of the log" because everything's in the journal, so that part isn't a problem. Rather than "is this in auth.log or syslog or thisservice.log", it'll always be in the journal. > let me cd into /var/log and see what filenames I can find You can filter journal entries by unit (-u) or by service identifier (-t). Often, though, I find it really useful to be able to see the adjacent entries from other services at the same time, since that can give some indication of what's happening on the system that caused an issue. > or grep everything until I can find a couple of words that make some sense so I can keep digging further journalctl --grep, or more conveniently, journalctl and then / to search. > The lack of explorability in journalctl It's explorable by dozens of different axes, and if all of those aren't sufficient, you always can get the whole thing as text and run any command you like on it, or get it in structured form and do structured queries on it.
deleted 2y ago
[deleted]

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.

iforgotpassword 2y ago
Huh, isn't grepping journalctl output pretty much the same? It even prefixes messages by the binary name.
- mdaniel 2y ago
  Pedantically, they're the unit name which only sometimes matches the binary name
  - rezonant 2y ago
    Actually no, they are prefixed by the binary name and the PID number. Technically they are prefixed with: `<date> <host> <binary>[<pid>]`. You can then use `systemctl status <pid>` to identify the unit if you need to. I would imagine this is configurable, and this might be the configuration chosen by my distribution (since I have not changed it myself). It would actually be nice to show the unit name instead of the binary/PID combination, though not strictly necessary. EDIT: Ooh, systemd 239 adds `journalctl -o with-unit` to do this exact thing. There are lots of other formats you can choose from as well. EDIT 2: Unfortunately there's no way to set this as default, you must use `-o with-unit` each time or set up a shell alias :-\
superb_dev 2y ago
Well `-u` refers to the unit file, so I would start with `sudo systemctl status` which lists the status of active unit files. I bet I could find the unit name I'm looking for there. If not, then `sudo systemctl list-units` should have it. (and you can grep the output of both) Systemd and Journald are less opaque than I used to think. Even if you don't want to learn the commands, all of its unit files (and the relationships between them) are available through the filesystem. Most of your unit files will be in `/etc/systemd/system`, and the active relationships between units are expressed through soft links.
- aeonik 2y ago
  How would you exclude certain units from your logs? Let's say that Auditd is spamming your logs, and you just want to exclude those? Can you filter on search? How do you prevent applications from writing to Systemd at all?
  - superb_dev 2y ago
    I would start with `man systemd`, or maybe `journalctl —help`. If you don’t want a service to log to systemd, then don’t run it in systemd?
    - pcthrowaway 2y ago
      I think you can also configure the journal per unit right? Don't remember how exactly, at the very least you can stream logs to a different system. There are also services which will just use their own logging convention for some reason. Honestly it's easier just to go with journalctl for everything you can.
- ramses0 2y ago
  systemctl does not have the Unix nature.
ciupicri 2y ago
# journalctl -f _PID=${your_pid} # option 1 # systemctl status ${your_pid} # option 2 [1]: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html#Examples https://www.freedesktop.org/software/systemd/man/latest/jour... [2]: https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#status%20PATTERN%E2%80%A6%7CPID%E2%80%A6%5D https://www.freedesktop.org/software/systemd/man/latest/syst...
- Brian_K_White 2y ago
  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.
  - throwaway7356 2y ago
    > 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.
  - robertlagrant 2y ago
sunshowers 2y ago
You do have to learn a few new things, yes. But it's not too difficult. We all have to learn new things sometimes. I spent around 15 minutes a few weeks ago learning how to do a few things with journalctl, and I came away from it with a great appreciation for its power.
rcxdude 2y ago
systemctl status <pid> will show you the unit and helpfully the last few lines of log from it. Journalctl -u <unit name> will then show you the full logs
JoshTriplett 2y ago
> Oh, I don´t know the name of the log for this process I can see in 'ps aux', With services using journald, there's no "name of the log" because everything's in the journal, so that part isn't a problem. Rather than "is this in auth.log or syslog or thisservice.log", it'll always be in the journal. > let me cd into /var/log and see what filenames I can find You can filter journal entries by unit (-u) or by service identifier (-t). Often, though, I find it really useful to be able to see the adjacent entries from other services at the same time, since that can give some indication of what's happening on the system that caused an issue. > or grep everything until I can find a couple of words that make some sense so I can keep digging further journalctl --grep, or more conveniently, journalctl and then / to search. > The lack of explorability in journalctl It's explorable by dozens of different axes, and if all of those aren't sufficient, you always can get the whole thing as text and run any command you like on it, or get it in structured form and do structured queries on it.

deleted 2y ago

[deleted]