4 ms·

While generally the systemd documentation is pretty good (Start with reading the original blog series as a primer, later search for "systemd directives" using y

While generally the systemd documentation is pretty good (Start with reading the original blog series as a primer, later search for "systemd directives" using your favourite search engine) I have always found the transactions concept underdocumented. Does anyone have a good link? Edit: Are transactions and jobs the same thing? Both are mentioned in the documentation here and there, without having an own page or chapter AFAIK.

egberts1 5y ago
“Documentation” is “Pretty Good? “Start with” the “blog”? Clearly, the two does not connect well … for systemd.
- jeppesen-io 5y ago
  > ... as a primer It's worked very well for me. Not seeing your disconnect here. Blog for concepts, man pages for specifics
  - noobermin 5y ago
    I wish more developers wrote enough into the man page so you don't need to google things. More of bash's man page and less of i3's.
    - throw0101a 5y ago
      Don't forget all the stuff in GNU's info pages.
      - badsectoracula 5y ago
        I'm of the opinion that "info" is for long form guides and "man" is for short references. (replace "info" with some better reader than the default one though)
  - egberts1 5y ago
    For instance, I wanted to know why my custom systemd.conf unit file is causing my custom daemon to restart whenever the Ethernet cord gets unplugged or its netdev goes offline.
- usr1106 5y ago
  It's open source, you get what you pay for. Actually, you get much more, but you need to fill any gaps with your own efforts. Accessing the spread out documentation is one of them. While they are not comparable entities I'd say systemd documentation is in better shape than Linux kernel documentation. (Not to negate the efforts of those who do work with kernel documentation, but to stress the huge areas of no or pretty obsolete documentation). Of course you can buy Linux (incl. user space) from the commercial players. I have only worked in one small project in my career that did, but I did not notice that better documentation was worth paying for.
  - rkachowski 5y ago
    The idea that good documentation requires payment is defeated by the huge amount of open source projects with excellent documentation.
    - usr1106 5y ago
      I did not say that every open source project produces insufficient documentation. But some central ones that are hard to avoid do. There complaining doesn't help, you just need to invest your efforts. Ideally you could contribute better documentation, but at least you have to make the effort to learn it for yourself.
  - pmontra 5y ago
    Paying for something doesn't guarantee good documentation. Example: I read many people complaining about Apple [1] My take is that pay vs free software and good vs bad documentation are orthogonal and you can be in any of the four quadrants. [1] https://www.reddit.com/r/swift/comments/ljl6bq/we_were_so_frustrated_by_apple_docs_that_we_made/ https://www.reddit.com/r/swift/comments/ljl6bq/we_were_so_fr...
    - Sebb767 5y ago
      > My take is that pay vs free software and good vs bad documentation are orthogonal and you can be in any of the four quadrants. It's definitely not independent. Few people enjoy writing documentation and even then, it takes a lot of time. Plus, writing good documentation is something you need to train for. Very few OS people want to spend their free time writing code and then spend just as much again for - usually boring - documentation and support tasks. Companies have exactly the same problem, but they have the option to throw money at the problem. Sure, there are some OS projects with good documentation (usually sponsored by a company) and a lot of proprietary stuff without, but proprietary software usually has more financial backing and that's directly related to good documentation.
- usr1106 5y ago
  > Clearly, the two does not connect well … for systemd It's linked from the man page. https://man7.org/linux/man-pages/man1/systemd.1.html https://man7.org/linux/man-pages/man1/systemd.1.html Unfortunately the reading will still need to do ourselves. Not trying to be snarky here, it happens to me all the time that I have not read something and complain it's hard to understand.
  - bosie 5y ago
    I think what OP means is that having good documentation should not require you to read a blog of any sorts, even if it is linked in the man page. Either documentation is good OR you read the blog, you cannot have both.
    - jcelerier 5y ago
      I disagree, for instance in a man page I don't want to read the rationale for something (which the blog provides), just the raw "if you do this, then that will happen". That would have its place in a GNU info book instead.
      - zozbot234 5y ago
        Plenty of man pages have a dedicated RATIONALE section. You don't have to read it, but the stuff is documented.
FriedrichN 5y ago
Is there a good resource for people who are used to non-systemd systems (something like a gotcha list)? I keep on running into weird situations where I end up finding out systemd is somehow responsible for my woes. Last time that happened was when I changed /etc/fstab but somehow old mounts kept on being remounted, I wasted an hour before I found out I had to reload some systemd service.
mkipper 5y ago
I'm not familiar with the term transactions, but it doesn't sound like it's the same as jobs. Jobs are externally visible. You can see them easily (e.g. systemctl list-jobs), and systemd provides an interface for them over D-Bus[1]. There's no similar interface for anything called a transaction. From the documentation that does mention transactions, it sounds like transactions are internal to systemd. When systemd starts a unit, it works out the dependency graph and spins up a job for each unit that need to be started before the originally requested unit can start. That would all be considered a single transaction, but it might spin out into dozens of separate jobs that get queued up. As an example, when systemd starts on boot, all it really wants to do is successfully reach some target (e.g. multi-user.target). systemd starts from there and works backwards, building a dependency graph with every single unit that needs to start up as a part of the boot sequence to reach that target. You could probably consider that a single transaction, but the full dependency graph would probably pull in hundreds of jobs. I don't work on systemd or anything so this isn't canon. [1] https://www.freedesktop.org/wiki/Software/systemd/dbus/ https://www.freedesktop.org/wiki/Software/systemd/dbus/

egberts1 5y ago

“Documentation” is “Pretty Good? “Start with” the “blog”? Clearly, the two does not connect well … for systemd.

jeppesen-io 5y ago
> ... as a primer It's worked very well for me. Not seeing your disconnect here. Blog for concepts, man pages for specifics
- noobermin 5y ago
  I wish more developers wrote enough into the man page so you don't need to google things. More of bash's man page and less of i3's.
  - throw0101a 5y ago
    Don't forget all the stuff in GNU's info pages.
    - badsectoracula 5y ago
      I'm of the opinion that "info" is for long form guides and "man" is for short references. (replace "info" with some better reader than the default one though)
- egberts1 5y ago
  For instance, I wanted to know why my custom systemd.conf unit file is causing my custom daemon to restart whenever the Ethernet cord gets unplugged or its netdev goes offline.
usr1106 5y ago
It's open source, you get what you pay for. Actually, you get much more, but you need to fill any gaps with your own efforts. Accessing the spread out documentation is one of them. While they are not comparable entities I'd say systemd documentation is in better shape than Linux kernel documentation. (Not to negate the efforts of those who do work with kernel documentation, but to stress the huge areas of no or pretty obsolete documentation). Of course you can buy Linux (incl. user space) from the commercial players. I have only worked in one small project in my career that did, but I did not notice that better documentation was worth paying for.
- rkachowski 5y ago
  The idea that good documentation requires payment is defeated by the huge amount of open source projects with excellent documentation.
  - usr1106 5y ago
    I did not say that every open source project produces insufficient documentation. But some central ones that are hard to avoid do. There complaining doesn't help, you just need to invest your efforts. Ideally you could contribute better documentation, but at least you have to make the effort to learn it for yourself.
- pmontra 5y ago
  Paying for something doesn't guarantee good documentation. Example: I read many people complaining about Apple [1] My take is that pay vs free software and good vs bad documentation are orthogonal and you can be in any of the four quadrants. [1] https://www.reddit.com/r/swift/comments/ljl6bq/we_were_so_frustrated_by_apple_docs_that_we_made/ https://www.reddit.com/r/swift/comments/ljl6bq/we_were_so_fr...
  - Sebb767 5y ago
    > My take is that pay vs free software and good vs bad documentation are orthogonal and you can be in any of the four quadrants. It's definitely not independent. Few people enjoy writing documentation and even then, it takes a lot of time. Plus, writing good documentation is something you need to train for. Very few OS people want to spend their free time writing code and then spend just as much again for - usually boring - documentation and support tasks. Companies have exactly the same problem, but they have the option to throw money at the problem. Sure, there are some OS projects with good documentation (usually sponsored by a company) and a lot of proprietary stuff without, but proprietary software usually has more financial backing and that's directly related to good documentation.
usr1106 5y ago
> Clearly, the two does not connect well … for systemd It's linked from the man page. https://man7.org/linux/man-pages/man1/systemd.1.html https://man7.org/linux/man-pages/man1/systemd.1.html Unfortunately the reading will still need to do ourselves. Not trying to be snarky here, it happens to me all the time that I have not read something and complain it's hard to understand.
- bosie 5y ago
  I think what OP means is that having good documentation should not require you to read a blog of any sorts, even if it is linked in the man page. Either documentation is good OR you read the blog, you cannot have both.
  - jcelerier 5y ago
    I disagree, for instance in a man page I don't want to read the rationale for something (which the blog provides), just the raw "if you do this, then that will happen". That would have its place in a GNU info book instead.
    - zozbot234 5y ago
      Plenty of man pages have a dedicated RATIONALE section. You don't have to read it, but the stuff is documented.

FriedrichN 5y ago

Is there a good resource for people who are used to non-systemd systems (something like a gotcha list)? I keep on running into weird situations where I end up finding out systemd is somehow responsible for my woes. Last time that happened was when I changed /etc/fstab but somehow old mounts kept on being remounted, I wasted an hour before I found out I had to reload some systemd service.

mkipper 5y ago

I'm not familiar with the term transactions, but it doesn't sound like it's the same as jobs. Jobs are externally visible. You can see them easily (e.g. systemctl list-jobs), and systemd provides an interface for them over D-Bus[1]. There's no similar interface for anything called a transaction. From the documentation that does mention transactions, it sounds like transactions are internal to systemd. When systemd starts a unit, it works out the dependency graph and spins up a job for each unit that need to be started before the originally requested unit can start. That would all be considered a single transaction, but it might spin out into dozens of separate jobs that get queued up. As an example, when systemd starts on boot, all it really wants to do is successfully reach some target (e.g. multi-user.target). systemd starts from there and works backwards, building a dependency graph with every single unit that needs to start up as a part of the boot sequence to reach that target. You could probably consider that a single transaction, but the full dependency graph would probably pull in hundreds of jobs. I don't work on systemd or anything so this isn't canon. [1] https://www.freedesktop.org/wiki/Software/systemd/dbus/ https://www.freedesktop.org/wiki/Software/systemd/dbus/