On 9/4/2012 3:43 PM, Claudio Freire wrote:
On Tue, Sep 4, 2012 at 4:10 PM, Andreas Jaeger <aj@suse.com> wrote:
Yes, and that's very good. But in 12.1, service status reporting was quite lacking with SystemD, and it was a SystemD shortcoming, not a packaging or training issue.
Can you give me an example so that we can compare with 12.2?
I'm planning to test 12.2 and let you know already. I just need to find the time.
I don't know yet whether it's been improved though, but if it hasn't, it should. Thing is, the people in charge of it were quite... opposed to it. For no reason other than "we don't want to". Hence all the griping. With such a predisposition, many (including me) feel uncomfortable leaving it as the only option to a very critical subsystem.
Perhaps it's such predisposition the thing that must change to improve SystemD acceptance.
I don't think you ever interacted properly with Frederic Crozat, who's "in charge" of systemd in openSUSE and did a lot for a proper integration - and convinced upstream also in some cases to change their "we don't want to".
I could dig the archives, but you're right, I got tired of the negative responses and just stopped reading the thread at the time (and skipped 12.1 as it was too troublesome for my setup). I'm sure things improved, and my kudos to Frederic for that. I'm just saying, it was a tough time that was imprinted on users' impression of SystemD.
As far as I know, there's still no integrated solution to the vmware status reporting case (which is incidentally equivalent to a few services I run). Upstream's unwillingness to provide such a simple facility is quite misterious.
Indeed. My particular worst offending problem was lxc. To properly manage lxc containers, you need to execute commands to find out the status of the vm, which means the status of the processes within the container. There is no single process you can look for and no single file you can watch in the simple way systemd demanded. Lxc is really just a set of utils that manipulate a set of kernel features. There is no lxc server. And you need to be able to test the containers status to shut down gracefully. You can send a signal to the containers init process and then you have to watch two different things to confidently say if the container is "down". The init process doesn't go away even when the system within the container is all down, so you can't watch that. Now, lxc is a very important feature/system and rapidly becoming a high profile jewel of linux, that WILL end up getting some sort of answer. Either systemd or the kernel will adapt to make it possible for systemd to correctly manage lxc containers. Probably vmware too. Well gee how nice for those two high profile special cases. The problem is it's just wrong to say that everything that can't either adapt to systemd or be so big and popular as to force systemd to adapt to it, is out of luck. Because it's not necessary. That attitude is a voluntary behavior of systemd, not a technical requirement that can't be avoided. In an init script I could have anything. Anything. Anything I might discover I need or want, without having to convince some jerk that I have a valid reason to do whatever I need to do. I could have a script that telnets to a remote machine and executes commands to find out the status of a pdu power jack, the temperature of a sensor, the presence or absence of a net connection, a combination of a fistfull of different things that all relate to each other, anything. Unless systemd has changed their tune, the only way I can do that in systemd is to write myself a special agent daemon that basically runs the script I really want, and provides the kind of simplistic interface that systemd can watch like a single process or a single file or a single socket. It would already be bad enough to have to merely run this needless extra process 24/7, let alone have to write it first. Saying "systemd supports init scripts" does not actually address the problem of status checking, and without status checking, you can not actually say it supports any services, or actions that aren't services, that need that. -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org