Mailinglist Archive: opensuse (1188 mails)
| < Previous | Next > |
[opensuse] Re: new to systemd - rcnetwork status - equivalent needed
- From: Joachim Schrod <jschrod@xxxxxxx>
- Date: Wed, 25 Jan 2012 20:35:36 +0100
- Message-id: <jfpli8$605$1@dough.gmane.org>
Patrick Shanahan wrote:
But that's not what cagsm wanted. He wanted the whole status info
that rcnetwork status used to output.
The problem here is, IMNSHO, a severe design mismatch on a high
level between the old init.d and the new systemd concept.
init.d looked at services as something very general. In fact,
anything that shall be started at boot time, ended at shutdown
time, or manually in-between, and that might output some status
info, is a service for init.d. Anything that might be of interest
for a human can be output by the services' status command.
For systemd, a service is an initialization of something, or a
group of running processes with a master process. A status info is
just the information which processes that are, as shown in the
example output above, and nothing more.
openSUSE systemd proponents, in particular Cristian Rodriguez, have
repeatedly called any further wish as unreasonable. I don't know if
that view is shared at systemd upstream development, though
postings that I've seen indicate that this might be the case (see
below for links).
If you want, you can read a discussion thread at the
opensuse-factory list archive with the subject "Re: Human readable,
what is that? (was [12.1] massive data loss in /var/tmp/)", mid to
end December. It quickly went downhill into a flame war between
systemd oponents and proponents, as happens so often. But inbetween
there were postings that presented several use cases for an
"ExecStatus" configuration possibility that executes an arbitrary
command to get the status. Particularly, LXC container status and
AppArmor status were mentioned. These were summarily discarded by
Cristian and others. (Cristian was the most vocally, that's why I
remember him specifically.) Actually, since their answers did not
address the actual use case parts that were cited as problematic, I
even prepared a summary post that tried to re-formulate them and
addressed specifically Cristian if he could react on these issues
technically and not in a polemic way. Sadly, Cristian didn't
answer. I don't know if he didn't see it, was fed up by the flame
war, or chose to ignore it for other reasons.
I don't know the state of the "ExecStatus" proposal upstream, the
first three Google page results didn't get me that information.
In August, Lennart was against it:
http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/3171.
In November, a bugzilla ticket mentions it might be needed, but Kay
was also very sceptical:
https://bugzilla.redhat.com/show_bug.cgi?id=754127 -- that ticket
is not yet closed.
In the source, there is a notion of ExecStatus in src/execute.[ch],
but I couldn't recognize at first glance if that is about the
existing restricted status notion of systemd, or about the eventual
introduction of a full ExecStatus configuration possibility.
Hope this summary of events that I have read about in the context
of service status helps.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod@xxxxxxx
Roedermark, Germany
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx
* cagsm <cumandgets0mem00f@xxxxxxxxx> [01-25-12 09:59]:
new to systemd - rcnetwork status - equivalent needed
wondering how i can list those nice details to all my network
interface cards and connections, like with rcnetwork status, and also
rcnetwork start dsl0 and so on.
systemd seems like a pita.
any good pointers? tia.
I have found that most of the rc..... utilities still function and a plus,
they provide the corresponding systemd function, ie:
10:01 Crash: ~ # rcnetwork status
redirecting to systemctl
network.service - LSB: Configure the localfs depending network interfaces
Loaded: loaded (/etc/init.d/network)
Active: active (running) since Sat, 21 Jan 2012 11:38:13 -0500; 3
days ago
CGroup: name=systemd:/system/network.service
├ 2394 /sbin/dhclient6 -6 -cf
-/var/lib/dhcp6/dhclient6.eth0.conf -/-lf
-/-/var/lib/dhcp6/dhclient6.eth0.lease -/-/-pf /var...
└ 6718 sbin/dhcpcd netconfig L -E HHH c
etc/sysconfig/network/scripts/dhcpcd-hook /-----/-t 0 h Crash eth0 10:02
Crash: ~ 3
note that line wrap will distort the information display. There are 8
lines. The systemd corresponding cmd comes after CGroup:...
systemctl status network.service
But that's not what cagsm wanted. He wanted the whole status info
that rcnetwork status used to output.
The problem here is, IMNSHO, a severe design mismatch on a high
level between the old init.d and the new systemd concept.
init.d looked at services as something very general. In fact,
anything that shall be started at boot time, ended at shutdown
time, or manually in-between, and that might output some status
info, is a service for init.d. Anything that might be of interest
for a human can be output by the services' status command.
For systemd, a service is an initialization of something, or a
group of running processes with a master process. A status info is
just the information which processes that are, as shown in the
example output above, and nothing more.
openSUSE systemd proponents, in particular Cristian Rodriguez, have
repeatedly called any further wish as unreasonable. I don't know if
that view is shared at systemd upstream development, though
postings that I've seen indicate that this might be the case (see
below for links).
If you want, you can read a discussion thread at the
opensuse-factory list archive with the subject "Re: Human readable,
what is that? (was [12.1] massive data loss in /var/tmp/)", mid to
end December. It quickly went downhill into a flame war between
systemd oponents and proponents, as happens so often. But inbetween
there were postings that presented several use cases for an
"ExecStatus" configuration possibility that executes an arbitrary
command to get the status. Particularly, LXC container status and
AppArmor status were mentioned. These were summarily discarded by
Cristian and others. (Cristian was the most vocally, that's why I
remember him specifically.) Actually, since their answers did not
address the actual use case parts that were cited as problematic, I
even prepared a summary post that tried to re-formulate them and
addressed specifically Cristian if he could react on these issues
technically and not in a polemic way. Sadly, Cristian didn't
answer. I don't know if he didn't see it, was fed up by the flame
war, or chose to ignore it for other reasons.
I don't know the state of the "ExecStatus" proposal upstream, the
first three Google page results didn't get me that information.
In August, Lennart was against it:
http://permalink.gmane.org/gmane.comp.sysutils.systemd.devel/3171.
In November, a bugzilla ticket mentions it might be needed, but Kay
was also very sceptical:
https://bugzilla.redhat.com/show_bug.cgi?id=754127 -- that ticket
is not yet closed.
In the source, there is a notion of ExecStatus in src/execute.[ch],
but I couldn't recognize at first glance if that is about the
existing restricted status notion of systemd, or about the eventual
introduction of a full ExecStatus configuration possibility.
Hope this summary of events that I have read about in the context
of service status helps.
Joachim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod@xxxxxxx
Roedermark, Germany
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx
| < Previous | Next > |