Comments by "Lawrence D’Oliveiro" (@lawrencedoliveiro9104) on "" video.

  1. 10:42 Fun fact: Debian used to use runlevel 3 as its normal mode of full multiuser GUI login. Which just goes to show how wonderfully inconsistent sysvinit could be. With systemd, all runlevels (now called “targets”) are identified symbolically, so you don’t have to figure out what cryptic numbers mean, because there aren’t any.
    9
  2. Back in the early days of the Macintosh, Alan Kay said a system should be designed so that “simple things are simple, and complex things are possible”. With sysvinit, simple things can be quite fiddly to do. As for complex things ... don’t expect them to work reliably. With systemd, it really is simple to do simple things. And it manages to get complex things working reliably, too.
    8
  3. 3:11 Not as far as I know. PID 1 is not automatically restarted if it dies; not only that, if PID 1 is ever terminated, your system goes down.
    7
  4. Ivan Toshkov is right, DJ Ware is wrong. Note this part from the linked article: “When orphan processes die, they do not remain as zombie processes; instead, they are waited on by init. The result is that a process that is both a zombie and an orphan will be reaped automatically.” Note that only applies to orphan processes. Non-orphaned zombies cannot be automatically reaped; their parent process must do this.
    6
  5.  @RHTORAS  Somebody should do a video comparing these different service-management systems in more detail, with actual examples. Enough of this hand-waving, particularly when emotions start to run high and rationality goes out the window.
    5
  6. It is very easy to interface existing applications and services to systemd. An example of this sort of thing popped up on the Waikato Linux User Group list a few months ago. I found this systemd service file in an online forum that someone had written to automatically apply a certain charging profile to their laptop battery on boot. The actual command was a single line of shell script; the rest of the dozen or so lines were directives defining when and how to run the command (e.g. specifying that it was “oneshot” invocation, so there would be no ongoing running process after the command had done its job). I reposted it because I thought it was a good example of the simplicity of systemd. Somebody more familiar with sysvinit tried posting an init.d-style script to do the same thing. It came to be about 50% larger, all but one line of which was just boilerplate.
    4
  7. Most Linux users do not use Red Hat, have never used Red Hat, will never use Red Hat. Other distros adopted systemd because it was better than any alternative they could think of. Ubuntu had its own upstart system, which it abandoned because it simply could not keep up with what systemd had achieved. There are distros around that don’t use systemd, whether for purely ideological reasons, or actually for practical ones. So you are free to use what you like. And if none of them seems to suit your needs, start a new one. Hundreds, thousands of people have already done exactly that, so it hardly takes any l33t sk1llz to manage it!
    4
  8. What’s cool is things like automatic rotation, and also the fact that the timestamps are timezone-agnostic. So you can display the logs according to any timezone you like.
    3
  9.  @terrydaktyllus1320  Logrotate is a clumsy fudge. Any seasoned sysadmin would have encountered this: the customer will report that a problem happened at a particular time in their timezone. This might not be the same as your timezone. And the timezone in which the server is located is the least important of all. So it’s nice to be able to match up events to the time that the customer reported.
    2
  10. 5:20 Doesn’t matter whether the child does an exec(2) call or not. It still remains a child of its parent.
    2
  11. How about man systemd-analyze just as a starting point ...
    2
  12. It never will, because it depends too much on Linux-specific functionality.
    2
  13.  @terrydaktyllus1320  Which commands are you referring to? They are all there for a purpose.
    2
  14.  @terrydaktyllus1320  Sorry, I didn’t read your comment any further.
    2
  15. As if SELinux from the NSA couldn’t already have done that ...
    2
  16. 6:07 kthreadd has nothing to do with any of this: it’s purely an internal kernel housekeeping mechanism. Remember, the semantics of userland processes is laid down by the POSIX spec, to which Linux adheres closely. systemd really makes no difference to this.
    2
  17. Remember that systemd is more than just “system initialization”. Linux is a very dynamic environment, where services can be started and stopped at times other than system boot. systemd is designed to cope with that.
    1
  18. 5:47 It’s worth clarifying what the whole point of this “parent/child” relationship, and consequent possibility of “orphan” processes, is about: when a process terminates, it becomes a “zombie”, which means it still takes up a process slot, even though no process is running any more. At this point, it is up to its parent to pick up a notification of the termination of the child, via a call like wait(2) or similar; once it gets this notification, then the zombie process disappears, and that process slot is freed up to hold a new created process. So, if you write a program on Linux or other POSIX-type system, and you spawn lots of processes, then you have to remember this rule to avoid your system running out of process slots: always gobble your zombie children.
    1
  19. POSIX behaviour is indeed for PID 1 to become the parent of orphaned processes. Linux offers some extra options, in the form of the prctl(2) call, to modify this, if you want. Otherwise the POSIX behaviour is the default.
    1
  20. Umm, just to be sure, I rechecked the POSIX spec, and it doesn’t actually say anything specifically about PID 1. All it says is that the parent is initially the process that created the child, and that “After the creator’s lifetime has ended, the parent process ID is the process ID of an implementation-defined system process”.
    1
  21. Just make sure they all agree that the hardware clock is to be interpreted as UTC. Unfortunately, this is not something you can set in Microsoft Windows.
    1
  22. It’s a service manager. Those are services. They need to be managed.
    1
  23.  @jamesmachado2224  Are you trying to suggest that liking systemd is akin to terrorism?
    1
  24. The Linux environment is a dynamic one; services can be started or stopped at any time, not just at boot time. systemd is designed to cope with this.
    1
  25. As an embedded developer you don’t have to worry about dependencies, since you can provide all the necessary ones in your installation image. Heck, you could probably put all your necessary startup/shutdown sequencing in a single rc.local-type file and dispense with sysvinit altogether. systemd is designed to cope with much more complex, dynamic and variable situations.
    1
  26.  @CyberGizmo  None of which has anything to do with the POSIX-specified behaviour of userland processes, which is what we are discussing here.
    1