On 06/15/2011 03:53 AM, Rahul Sundaram wrote: > On 06/15/2011 02:34 PM, Ed Greshko wrote: >> I must admit that I've not spent much time to digest what advantages >> there are to moving to systemd. However, it does seem to be quite a >> complex system with, as of yet, hard to locate documentation. I've also >> not had to debug any start up failures...but wanted to learn more about >> systemctl. > > https://fedoraproject.org/wiki/Systemd > >> While it is only a blog entry between developers of systemd I did run >> into this gem which, at first blush, makes me apprehensive. > > bochecha is not a systemd developer 'bochecha' was not the person who wrote the blog response that Ed Greshko quoted, he was the person to whom the text was addressed. The quoted response was written by Lennart if that changes your assessment of its credibility. See the first comment in: http://0pointer.de/blog/projects/systemd-for-admins-1.html Also, why does the source's developer status matter? Is there something wrong about the information (which I repeat below)? If so, what? I also am interested in answers to the questions Ed Greshko asked. ==== bochecha: well, there are many reasons why a service might show up as failed to load in the systemctl output: for example, it was referenced as required dependency of another service, but we couldn't find neither a native service definition file nor a SysV init script for it. Or, there was a parsing failure while reading it. Or, because the file was incomplete. And that might even happen while a service is active, for example, because the user requested a configuration file reload from systemd after changing a service file, and a service that is already running suddenly has an invalid configuration file. That effectively means that the LOAD and the ACTIVE state are mostly orthogonal: you may have a running service where configuration loaded fine, you may have a stopped service where it loaded fine, but you may also have a running service where configuration failed to load. And yes, ACTIVE and SUB show you the same information, though ACTIVE in a more generalized form. While SUB has states that are specific to each unit type (e.g. "running", "exited", "dead" for services; "plugged" and "dead" for devices; or "mounted" and "dead" for mount points), ACTIVE exposes the same high-level states for all units. We only distinguish 6 ACTIVE states (to list them: active, reloading, inactive, maintenance, activating, deactivating), which are mapped from the lower-level states, which might be many more. For example services have 15 low-level states: dead, start-pre, start, start-post, running, exited, reload, stop, stop-sigterm, stop-sigkill, stop-post, final-sigterm, final-sigkill, maintenance, auto-restart. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
