Re: [systemd-devel] Monitoring services start event from kdbus with sd-bus API
First, are you actually switching your bus connection to monitor mode? In
kdbus (and probably even in future DBus) there is a distinct monitor mode
which must be enabled to capture other peers' bus traffic. Adding a match
is not enough for that.
Second, your approach won't work anyway. There *won't be* method_calls for
services that are started as dependencies, there won't be method calls for
socket-activated services, there won't be method calls for DBus-activated
services, there probably won't be even a single Start call during the
entire boot process. Systemd won't bother calling itself over DBus for that.
Instead, why not use the *signals* that systemd sends, for exactly such
purposes? You'll need to call Subscribe() to enable them.
See also what Plymouth does for its splash screen.
On Tue, Jun 30, 2015, 12:15 Thomas Schmidt t.schm...@md-network.de wrote:
Hello,
for an embedded project I’m implementing a bootsplash application which
should as well display service names are starting.
This is based on kdbus and uses the sd-bus API to communicate with systemd
(for example boot process percentage property is polled).
Now I try to monitor the kdbus (system bus) to capture the events which
indicate that a service was started. (works very well for testing with
busctl monitor“ tool).
I assumed that the method_call „StartUnit“ would be a good indicator, so I
tried to monitor for those messages by using following code (shortened and
only significant parts copied here):
-.-.-.-.-.-.-.-.-.-.-. schnipp -.-.-.-.-.-.-.-.-.-.-
r = sd_bus_open_system(bus);
…
r = sd_bus_add_match(bus, NULL, , do_something_callback, NULL); /*
should not filter anything, I expect it triggers on any message */
…
for (;;) {
sd_bus_message *m = NULL;
r = sd_bus_process(bus, m);
if (r 0) {
fprintf(stderr, Failed to process bus: %s\n,
strerror(-r));
goto finish;
}
if (r 0) /* we processed a request, try to process
another one, right-away */
continue;
/* Wait for the next request to process */
r = sd_bus_wait(bus, (uint64_t) -1);
if (r 0) {
fprintf(stderr, Failed to wait on bus: %s\n,
strerror(-r));
goto finish;
}
}
…
-.-.-.-.-.-.-.-.-.-.-. schnapp -.-.-.-.-.-.-.-.-.-.-
The interesting thing is that this code only sees „signal“ type messages
- but not any other like „method_call“.
I did extensive testing, tried different code variants, for example by
processing sd_bus_message *m“ directly in the for loop with
„sd_bus_message_is_method_call“ - but the effect is the same I don’t get
„method_call“ as an event.
Is there any suggestion what could be the reason ? (is that generally the
right way what I try here to do ?)
Many thanks for any feedback which points me to the right direction
Kind Regards
Thomas Schmidt
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Monitoring services start event from kdbus with sd-bus API
On 30/06/15 10:15, Thomas Schmidt wrote: r = sd_bus_add_match(bus, NULL, , do_something_callback, NULL); /* should not filter anything, I expect it triggers on any message */ Eavesdropping (adding match rules with AddMatch to receive messages that are neither a broadcast, nor directed to you) has never worked reliably on the system bus in traditional D-Bus, cannot be made reliable on the system bus without introducing security flaws, and does not exist at all in kdbus. Monitoring is the modern replacement for eavesdropping: it puts your connection in a special mode where it receives other people's messages, but cannot send messages or do other normal D-Bus things. kdbus has only ever had monitoring, not eavesdropping, and I added a vaguely similar monitoring mode to dbus-daemon in the 1.9.x development branch. Monitoring and eavesdropping are both unusual things that should only be used as a diagnostic, and not in production code. Think of them as equivalent to putting your network interface in promiscuous mode for something like tcpdump - you can do that as a developer or sysadmin to debug problems or detect bad behaviour, but you shouldn't write ordinary networking applications that rely on it. The interesting thing is that this code only sees „signal“ type messages - but not any other like „method_call“. That is consistent with the way in which eavesdropping has never really worked as intended on the system bus. Further reading: https://bugs.freedesktop.org/show_bug.cgi?id=46787 -- Simon McVittie Collabora Ltd. http://www.collabora.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto handle one time shutdown programs
On Tue, Jun 30, 2015 at 2:35 PM, Andreas Buschmann busch...@tech.net.de wrote: Hello Johannes, On Thu 25-Jun-2015 20:09 CEST Johannes Ernst writes: On Jun 25, 2015, at 7:57, Andreas Buschmann busch...@tech.net.de wrote: I am writing a systemd .service file to handle NVDIMMs. - start - stop - reload all work The problem child is restart. Restart is internally implemented as stop followed by start. The problem is, that stop calls a program which does something to the NVDIMM hardware. After that no further access to the NVDIMMs is possible before the next reboot of the server. How should I handle that sort of logic with systemd? How is that different from the user executing: systemctl start your.service systemctl stop your.service systemctl start your.service without reboot? It is not different, but that sequence can not work with my implementation of the service. systemctl stop your.service can only be called once. My stop script shuts down the hardware. Think like parking a hard disk. I am not sure on how to do that the systemd way. I have no problem with spliting the service up into myservice1 and myservice2, but than myservice2 has to be called exactly once before a shutdown or a reboot completes. You could place separate shutdown hook in /usr/lib/systemd/system-shutdown/. Note that all executables there are run concurrently in case it matters. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Delaying device service creation
Hi, I have a service 'A' which creates a device 'X' and does some configuring of the device. The device is created in a 'ExecStart=' directive whereas its configuration happens during 'ExecStartPost='. But it seems that as soon as the device is seen by systemd, it creates the corresponding device service and starts all services that depeneds on this device. However this happens even if service 'A' hasn't finished to configure the device yet. I tried to add 'Before=X.device' in 'A' service file, but it doesn't seem to have any effects. Could anybody help me ? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] getent hosts machine
Colin Guthrie wrote on 30/06/15 11:58: Johannes Ernst wrote on 29/06/15 19:51: On Jun 29, 2015, at 10:32, Johannes Ernst johannes.er...@gmail.com mailto:johannes.er...@gmail.com wrote: I was hoping that getent hosts containername would work, just like getent hosts hostname where hostname can be anything else in the hosts: field in nsswitch.conf. But no such luck. The containername does get resolved correctly in other cases, e.g. when pinging it. Not knowing how getent actually works, I don’t know why that is, but I figured I mention it. I take it back. A reboot fixed it. It appears I had a different problem: machinectl (suddenly) stopped showing any containers, but ps still showed several systemd-nspawn processes. FWIW, my machine is also currently in that state: [root@jimmy ~]# pgrep systemd-nspawn 25917 [root@jimmy ~]# ps aux | grep [s]ystemd-nspawn root 25917 0.0 0.0 15380 200 ?Ss Jun26 0:00 /usr/bin/systemd-nspawn -b -M tl.dev -D /home/colin/Development/Work/container7 --bind=/home/colin/Development/Work/trunk [root@jimmy ~]# machinectl MACHINE CLASS SERVICE 0 machines listed. Not sure what caused it (machined logs say it was terminated just under 15mins after it started) I did have issues that a previous machine was not marked as having been stopped (i.e. machinectl listed it after I'd stop the service unit for the machine and systemd-nspawn processes had gone - pretty much the opposite problem!). I edited my unit file to rename the -M argument passed to systemd nspawn and reloaded systemd to reread the unit. I notice that machined said my old machine name terminated at the same time systemd was reloaded... What adds to the curiosity now I look at my logs, the current name was also ejected when I reloaded systemd again. Jun 26 13:58:44 jimmy systemd[1]: Reloading. Jun 26 13:58:44 jimmy systemd-machined[16851]: Machine tl.dev7 terminated. Jun 26 13:58:44 jimmy systemd[1]: Failed to enumerate devices: Invalid argument Jun 26 13:58:44 jimmy systemd[1]: Failed to reload: Invalid argument Jun 26 14:13:40 jimmy systemd[1]: Reloading. Jun 26 14:13:41 jimmy systemd-machined[16851]: Machine tl.dev terminated. Jun 26 14:13:41 jimmy systemd[1]: Failed to enumerate devices: Invalid argument Jun 26 14:13:41 jimmy systemd[1]: Failed to reload: Invalid argument Random guess: Perhaps machined is using fd storage facility of systemd and the reload borks it and it sees it as the machine going away? On a hunch I reverted https://github.com/systemd/systemd/commit/9b420b3cfb8b93daf50e4cdbc92b05f2209ef893 and this seemed to fix this issue for me. I'll do some more tests, but with this reverted, restarting the service on the host works well (not tried reboots from within the container itself tho'). But anyway, multiple systemctl daemon-reloads since and machined is still keeping track nicely. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
Options: - Configure it as part of ExecStart if possible. - Configure it using a second .service unit (oneshot), and depend on that one. - Do something with udev to mark unconfigured devices with SYSTEMD_READY=0? Not sure how. But if you can do this, it'll directly affect the readiness of the corresponding .device unit. On Tue, Jun 30, 2015, 18:37 Francis Moreau francis.m...@gmail.com wrote: Hi, I have a service 'A' which creates a device 'X' and does some configuring of the device. The device is created in a 'ExecStart=' directive whereas its configuration happens during 'ExecStartPost='. But it seems that as soon as the device is seen by systemd, it creates the corresponding device service and starts all services that depeneds on this device. However this happens even if service 'A' hasn't finished to configure the device yet. I tried to add 'Before=X.device' in 'A' service file, but it doesn't seem to have any effects. Could anybody help me ? Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about ExecStartPost= and startup process
On 06/29/2015 10:05 AM, Andrei Borzenkov wrote:
[...]
service_sigchld_event() {
...
} else if (s-control_pid == pid) {
...
if (s-control_command
s-control_command-command_next
f == SERVICE_SUCCESS) {
service_run_next_control(s);
}
this looks like that forking type services could had several commands
queued in ExecStart directive...
IIRC this is checked when unit definition is parsed.
I don't think so, service_sigchld_event() is called when a child process
of systemd has just died and the condition is testing if the died
process is the process defined by ExecStart=.
Well it's my understanding, hence my confusion.
Thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Monitoring services start event from kdbus with sd-bus API
Hello,
for an embedded project I’m implementing a bootsplash application which should
as well display service names are starting.
This is based on kdbus and uses the sd-bus API to communicate with systemd (for
example boot process percentage property is polled).
Now I try to monitor the kdbus (system bus) to capture the events which
indicate that a service was started. (works very well for testing with busctl
monitor“ tool).
I assumed that the method_call „StartUnit“ would be a good indicator, so I
tried to monitor for those messages by using following code (shortened and only
significant parts copied here):
-.-.-.-.-.-.-.-.-.-.-. schnipp -.-.-.-.-.-.-.-.-.-.-
r = sd_bus_open_system(bus);
…
r = sd_bus_add_match(bus, NULL, , do_something_callback, NULL); /* should
not filter anything, I expect it triggers on any message */
…
for (;;) {
sd_bus_message *m = NULL;
r = sd_bus_process(bus, m);
if (r 0) {
fprintf(stderr, Failed to process bus: %s\n,
strerror(-r));
goto finish;
}
if (r 0) /* we processed a request, try to process another
one, right-away */
continue;
/* Wait for the next request to process */
r = sd_bus_wait(bus, (uint64_t) -1);
if (r 0) {
fprintf(stderr, Failed to wait on bus: %s\n,
strerror(-r));
goto finish;
}
}
…
-.-.-.-.-.-.-.-.-.-.-. schnapp -.-.-.-.-.-.-.-.-.-.-
The interesting thing is that this code only sees „signal“ type messages - but
not any other like „method_call“.
I did extensive testing, tried different code variants, for example by
processing sd_bus_message *m“ directly in the for loop with
„sd_bus_message_is_method_call“ - but the effect is the same I don’t get
„method_call“ as an event.
Is there any suggestion what could be the reason ? (is that generally the right
way what I try here to do ?)
Many thanks for any feedback which points me to the right direction
Kind Regards
Thomas Schmidt
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] howto handle one time shutdown programs
Hello Johannes, On Thu 25-Jun-2015 20:09 CEST Johannes Ernst writes: On Jun 25, 2015, at 7:57, Andreas Buschmann busch...@tech.net.de wrote: I am writing a systemd .service file to handle NVDIMMs. - start - stop - reload all work The problem child is restart. Restart is internally implemented as stop followed by start. The problem is, that stop calls a program which does something to the NVDIMM hardware. After that no further access to the NVDIMMs is possible before the next reboot of the server. How should I handle that sort of logic with systemd? How is that different from the user executing: systemctl start your.service systemctl stop your.service systemctl start your.service without reboot? It is not different, but that sequence can not work with my implementation of the service. systemctl stop your.service can only be called once. My stop script shuts down the hardware. Think like parking a hard disk. I am not sure on how to do that the systemd way. I have no problem with spliting the service up into myservice1 and myservice2, but than myservice2 has to be called exactly once before a shutdown or a reboot completes. Mit freundlichen Gruessen Andreas Buschmann p.s. I am not trying to convert an existing sysv init script to a systemd one. This is a new hardware. There is no init script. If I had to write a sysv initscript I would do something like Andrei described. -- Andreas Buschmann [Senior Systems Engineer] net.DE AG Büttnerstraße 57 D-30165 Hannover ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
