3 ms·

Regarding file ownership, not necessarily. If you run it as a session-based init, they'd be owned by the user it serves as an agent to. Interesting. I didn't

Regarding file ownership, not necessarily. If you run it as a session-based init, they'd be owned by the user it serves as an agent to. Interesting. I didn't realize systemd had a "user mode" where it doesn't run as pid 1. Does systemd run as root (or root equivalent) in this mode? I wasn't able to find this from a quick skim of the information available online. Upstart and launchd do not have the same issues. Upstart doesn't have dependencies, but named preconditions and postconditions. launchd has neither that nor dependencies. They have many problems of their own, but different ones. Sorry, but I have to disagree. The terminology may be different, but ultimately upstart's "start on" directive establishes a dependency. Once you have a dependency you can have circular dependencies. And once you rely on the init systems to establish ordering rather than having everything just start up in a deterministic order in simple single-threaded script, you can have race conditions where things happen to work on one machine but not another. I'm not as familiar with launchd; maybe its socket activation makes the circular ordering harder to hit, but fundamentally there can always be races. I'd assume the limited use of C/R to simply cut down initialization times is feasible: http://criu.org/Usage_scenarios#Slow-boot_services_speed_up http://criu.org/Usage_scenarios#Slow-boot_services_speed_up Perhaps for some processes this is feasible, but nothing on that site addresses my objections above: "some processes deal with state in the external world, or with hardware, that makes checkpointing infeasible." You will always need a notification mechanism even if you have checkpoint and restore. And why have the complexity of checkpointing if you have a working notification system? Running shell scripts doesn't mean much when the underlying system has a large surface and ill-defined module boundaries. A plugin system most certainly does not have to be complicated: look at finit and initng for examples. From a user's point of view, I do not want a plugin system. I want systemd to work the same on SUSE vs. debian vs. Red Hat. It is usually better to put things into the base system than to have them live in a half-supported state outside the tree. That's why web browsers are killing plugins: in order to be useful, they have to reach deep into the guts of the program, which is not a place I want 3rd party code. What about journald did you not understand? You lose control over the separate stages of collection, rotation and processing. Particularly having custom postprocessing is important for interoperability with foreign services that might expect certain format constraints. I don't understand why I would want separate daemons for collection and rotation, at least for dmsg, kmsg, and syslog. logrotate always had a bunch of race conditions; it was never a great design. I agree that journald doesn't do custom processing. However, I'm a little unsure whether I would really want it to, or whether I'd be better off running my own syslogd implementation at that point. That is still an option, even when you are using the rest of systemd. Having the logs be per-service instead of globally snarfed is also saner. You can always set up important services to log to a file rather than to syslog. My real criticism of systemd is that they made no effort at portability outside of Linux (and I don't buy their arguments about why it's too hard.) It would have been a lot less controversial if they had at least pointed out how the BSDs could add support (even if they themselves didn't do the work).

vezzy-fnord 11y ago
Once you have a dependency you can have circular dependencies. Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as discussed. (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) And once you rely on the init systems to establish ordering rather than having everything just start up in a deterministic order in simple single-threaded script, you can have race conditions where things happen to work on one machine but not another. Systems having ordering dependencies does not inherently affect their determinism, the startup discipline (sequential v. parallel) primarily does, and then there are different ways to tackle parallelism. systemd's execution model and transactional object system exacerbate non-determinism in ordering results. I don't understand why I would want separate daemons for collection and rotation, at least for dmsg, kmsg, and syslog. logrotate always had a bunch of race conditions; it was never a great design. They're not separate daemons. My real criticism of systemd is that they made no effort at portability outside of Linux (and I don't buy their arguments about why it's too hard.) That's a horrible criticism of systemd. Any cursory examination of systemd will quickly reveal the task is next to insurmountable without doing what amounts to a full reimplementation.
- mercurial 11y ago
  > (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) I agree with that point. This would ensure it can start with the last known-good configuration (though there is a chicken-and-egg problem here). As a user of XMonad, it's nice to know that I can mess up my "configuration file" (which is just Haskell code) without worries (unlike with what a WM like Awesome), which is probably the only thing about having Turing-complete configuration language I like.
- colin_mccabe 11y ago
  Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as discussed. What specific aspects of the systemd dependency model do you feel exacerbate race conditions and circular dependencies? (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) I have seen people discussing systemd error messages about circular dependencies online. It seems that systemd does perform some checking, although I haven't found documentation on what checks it does (I probably missed it). I'm not sure how the dependency graph could be persistent configuration because hardware can be hotplugged these days. For example, are you going to create nodes in the graph for all the hard drives that could possibly exist over the lifetime of the machine? Systems having ordering dependencies does not inherently affect their determinism, the startup discipline (sequential v. parallel) primarily does, and then there are different ways to tackle parallelism. systemd's execution model and transactional object system exacerbate non-determinism in ordering results. If the sequential vs. parallel startup discipline "primarily affects determinism" won't all these systems have the same issues with nondeterminism? I don't think anyone is seriously proposing starting up services on boot sequentially in 2015. Or even when a USB stick is inserted. Systems have 12 cores now and people can be very sensitive to boot times. [lack of portability is] a horrible criticism of systemd. Any cursory examination of systemd will quickly reveal the task is next to insurmountable without doing what amounts to a full reimplementation. I understand that systemd relies heavily on cgroups and other Linux-specific features for process isolation. And the BSDs are also unlikely to accept GPLed code. However, I feel like they could have at least discussed some way of reducing fragmentation here. As it is, I would be amazed if at least one or two of the BSDs didn't implement a similar init system to systemd in the next few years. And as it is, they probably won't share any code or concepts, unfortunately.

vezzy-fnord 11y ago

Once you have a dependency you can have circular dependencies. Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as discussed. (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) And once you rely on the init systems to establish ordering rather than having everything just start up in a deterministic order in simple single-threaded script, you can have race conditions where things happen to work on one machine but not another. Systems having ordering dependencies does not inherently affect their determinism, the startup discipline (sequential v. parallel) primarily does, and then there are different ways to tackle parallelism. systemd's execution model and transactional object system exacerbate non-determinism in ordering results. I don't understand why I would want separate daemons for collection and rotation, at least for dmsg, kmsg, and syslog. logrotate always had a bunch of race conditions; it was never a great design. They're not separate daemons. My real criticism of systemd is that they made no effort at portability outside of Linux (and I don't buy their arguments about why it's too hard.) That's a horrible criticism of systemd. Any cursory examination of systemd will quickly reveal the task is next to insurmountable without doing what amounts to a full reimplementation.

mercurial 11y ago
> (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) I agree with that point. This would ensure it can start with the last known-good configuration (though there is a chicken-and-egg problem here). As a user of XMonad, it's nice to know that I can mess up my "configuration file" (which is just Haskell code) without worries (unlike with what a WM like Awesome), which is probably the only thing about having Turing-complete configuration language I like.
colin_mccabe 11y ago
Then the question becomes whether an architecture obscures or exacerbates them, and also how it deals with them. The systemd object model does not fare well, as discussed. What specific aspects of the systemd dependency model do you feel exacerbate race conditions and circular dependencies? (Also compare a system like s6-rc or serel where dependency graphs are compiled from manifests and consistency checked before being applied. The graph is persistent configuration and not an ephemeral artifact.) I have seen people discussing systemd error messages about circular dependencies online. It seems that systemd does perform some checking, although I haven't found documentation on what checks it does (I probably missed it). I'm not sure how the dependency graph could be persistent configuration because hardware can be hotplugged these days. For example, are you going to create nodes in the graph for all the hard drives that could possibly exist over the lifetime of the machine? Systems having ordering dependencies does not inherently affect their determinism, the startup discipline (sequential v. parallel) primarily does, and then there are different ways to tackle parallelism. systemd's execution model and transactional object system exacerbate non-determinism in ordering results. If the sequential vs. parallel startup discipline "primarily affects determinism" won't all these systems have the same issues with nondeterminism? I don't think anyone is seriously proposing starting up services on boot sequentially in 2015. Or even when a USB stick is inserted. Systems have 12 cores now and people can be very sensitive to boot times. [lack of portability is] a horrible criticism of systemd. Any cursory examination of systemd will quickly reveal the task is next to insurmountable without doing what amounts to a full reimplementation. I understand that systemd relies heavily on cgroups and other Linux-specific features for process isolation. And the BSDs are also unlikely to accept GPLed code. However, I feel like they could have at least discussed some way of reducing fragmentation here. As it is, I would be amazed if at least one or two of the BSDs didn't implement a similar init system to systemd in the next few years. And as it is, they probably won't share any code or concepts, unfortunately.