Patrick Shanahan wrote:
* cagsm
[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@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org