[systemd-devel] [RFC PATCH] service: add FailureAction= option
It has the same possible values as StartLimitAction= and is executed
immediately if a service fails.
---
Hi Lennart,
Something like this maybe? I'm not quite sure about the condition in
service_enter_dead(). I don't think the action should be executed when the
service is explicitly stopped. Maybe it should depend on !forbid_restart?
If you like, I'll add some documentation. An maybe a follow-up patch to
rename the StartLimitAction type? To what though?
Regards,
Michael
src/core/dbus-service.c | 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/service.c| 31 ---
src/core/service.h| 2 ++
4 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index 0451790..1e710e3 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -50,6 +50,7 @@ const sd_bus_vtable bus_service_vtable[] = {
SD_BUS_PROPERTY(StartLimitInterval, t, bus_property_get_usec,
offsetof(Service, start_limit.interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(StartLimitBurst, u, bus_property_get_unsigned,
offsetof(Service, start_limit.burst), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(StartLimitAction, s,
property_get_start_limit_action, offsetof(Service, start_limit_action),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(FailureAction, s, property_get_start_limit_action,
offsetof(Service, failure_action), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(PermissionsStartOnly, b, bus_property_get_bool,
offsetof(Service, permissions_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RootDirectoryStartOnly, b, bus_property_get_bool,
offsetof(Service, root_directory_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RemainAfterExit, b, bus_property_get_bool,
offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index dbb5d13..dc83247 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -180,6 +180,7 @@ Service.WatchdogSec, config_parse_sec,
0,
Service.StartLimitInterval, config_parse_sec, 0,
offsetof(Service, start_limit.interval)
Service.StartLimitBurst, config_parse_unsigned, 0,
offsetof(Service, start_limit.burst)
Service.StartLimitAction,config_parse_start_limit_action,0,
offsetof(Service, start_limit_action)
+Service.FailureAction, config_parse_start_limit_action,0,
offsetof(Service, failure_action)
Service.Type,config_parse_service_type, 0,
offsetof(Service, type)
Service.Restart, config_parse_service_restart, 0,
offsetof(Service, restart)
Service.PermissionsStartOnly,config_parse_bool, 0,
offsetof(Service, permissions_start_only)
diff --git a/src/core/service.c b/src/core/service.c
index ae3695a..ab161a5 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1835,6 +1835,8 @@ static int cgroup_good(Service *s) {
return !r;
}
+static int service_execute_action(Service *s, StartLimitAction action, const
char *reason);
+
static void service_enter_dead(Service *s, ServiceResult f, bool
allow_restart) {
int r;
assert(s);
@@ -1844,7 +1846,9 @@ static void service_enter_dead(Service *s, ServiceResult
f, bool allow_restart)
service_set_state(s, s-result != SERVICE_SUCCESS ? SERVICE_FAILED :
SERVICE_DEAD);
-if (allow_restart
+if (s-result != SERVICE_SUCCESS s-failure_action !=
SERVICE_START_LIMIT_NONE)
+service_execute_action(s, s-failure_action, failed);
+else if (allow_restart
!s-forbid_restart
(s-restart == SERVICE_RESTART_ALWAYS ||
(s-restart == SERVICE_RESTART_ON_SUCCESS s-result ==
SERVICE_SUCCESS) ||
@@ -2366,18 +2370,14 @@ fail:
service_enter_stop(s, SERVICE_FAILURE_RESOURCES);
}
-static int service_start_limit_test(Service *s) {
+static int service_execute_action(Service *s, StartLimitAction action, const
char *reason) {
assert(s);
-if (ratelimit_test(s-start_limit))
-return 0;
-
-switch (s-start_limit_action) {
+switch (action) {
case SERVICE_START_LIMIT_NONE:
log_warning_unit(UNIT(s)-id,
- %s start request repeated too quickly,
refusing to start.,
- UNIT(s)-id);
+ %s %s, refusing to start., UNIT(s)-id,
reason);
Re: [systemd-devel] [RFC PATCH] service: add FailureAction= option
On 03/26/2014 09:02 AM, Michael Olbrich wrote: It has the same possible values as StartLimitAction= and is executed immediately if a service fails. --- Hi Lennart, Something like this maybe? I'm not quite sure about the condition in service_enter_dead(). I don't think the action should be executed when the service is explicitly stopped. Maybe it should depend on !forbid_restart? If you like, I'll add some documentation. An maybe a follow-up patch to rename the StartLimitAction type? To what though? Dont we already have OnFailure= for this ( or can be used for this instead of introducing FailureAction= which can be confusing to users )? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com: On 25 March 2014 18:01, Kai Hendry hen...@webconverger.com wrote: Requires=dev-input-by\x2did-usb\x2d13ba_0001\x2devent\x2dkbd.device On #systemd IRC I was recommended After=, and I think it's working as it should! After=dev-input-by\x2did-usb\x2d13ba_0001\x2devent\x2dkbd.device Is Requires= incorrect? Is my escaping correct? Do I need to actually escape in the first place? Hm, I'm not sure if After is the right solution. What if your keyboard is not attached during boot? If your daemon is not functional if the hardware is not present, I'd probably start it via a udev rule and SYSTEMD_WANTS. In addition, if you want your service is stopped whenever the hardware goes away, you can use BindTo in the service file -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] service: add FailureAction= option
On Wed, Mar 26, 2014 at 10:19:53AM +, Jóhann B. Guðmundsson wrote: On 03/26/2014 09:02 AM, Michael Olbrich wrote: It has the same possible values as StartLimitAction= and is executed immediately if a service fails. --- Hi Lennart, Something like this maybe? I'm not quite sure about the condition in service_enter_dead(). I don't think the action should be executed when the service is explicitly stopped. Maybe it should depend on !forbid_restart? If you like, I'll add some documentation. An maybe a follow-up patch to rename the StartLimitAction type? To what though? Dont we already have OnFailure= for this ( or can be used for this instead of introducing FailureAction= which can be confusing to users )? No. Take a look at the possible actions. This is intended to be used e.g. in combination with watchdogs. A unit that may or may not start cannot express 'reboot right now'. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] test-resolve.c: Cleanup and make use of sockaddr_pretty()
---
src/libsystemd/sd-resolve/test-resolve.c | 48 +++-
1 file changed, 22 insertions(+), 26 deletions(-)
diff --git a/src/libsystemd/sd-resolve/test-resolve.c
b/src/libsystemd/sd-resolve/test-resolve.c
index d3b2d55..6334dad 100644
--- a/src/libsystemd/sd-resolve/test-resolve.c
+++ b/src/libsystemd/sd-resolve/test-resolve.c
@@ -4,6 +4,7 @@
This file is part of systemd.
Copyright 2005-2008 Lennart Poettering
+ Copyright 2014 Daniel Buch
systemd is free software; you can redistribute it and/or modify it
under the terms of the GNU Lesser General Public License as published by
@@ -31,36 +32,39 @@
#include signal.h
#include errno.h
+#include socket-util.h
#include sd-resolve.h
#include resolve-util.h
#include macro.h
int main(int argc, char *argv[]) {
-int r = 1;
+int r = 0;
_cleanup_resolve_unref_ sd_resolve *resolve = NULL;
_cleanup_resolve_addrinfo_free_ struct addrinfo *ai = NULL;
_cleanup_free_ unsigned char *srv = NULL;
-sd_resolve_query *q1 = NULL, *q2 = NULL, *q3 = NULL;
-struct addrinfo hints = {};
-struct sockaddr_in sa = {};
_cleanup_free_ char *host = NULL, *serv = NULL;
+sd_resolve_query *q1 = NULL, *q2 = NULL, *q3 = NULL;
+
+struct addrinfo hints = {
+.ai_family = PF_UNSPEC,
+.ai_socktype = SOCK_STREAM,
+.ai_flags = AI_CANONNAME
+};
+
+struct sockaddr_in sa = {
+.sin_family = AF_INET,
+.sin_port = htons(80)
+};
assert_se(sd_resolve_new(resolve) = 0);
/* Make a name - address query */
-hints.ai_family = PF_UNSPEC;
-hints.ai_socktype = SOCK_STREAM;
-hints.ai_flags = AI_CANONNAME;
-
r = sd_resolve_getaddrinfo(resolve, q1, argc = 2 ? argv[1] :
www.heise.de, NULL, hints);
if (r 0)
log_error(sd_resolve_getaddrinfo(): %s\n, strerror(-r));
/* Make an address - name query */
-sa.sin_family = AF_INET;
-sa.sin_addr.s_addr = inet_addr(argc = 3 ? argv[2] : 193.99.144.71);
-sa.sin_port = htons(80);
-
+sa.sin_addr.s_addr = inet_addr(argc = 3 ? argv[2] : 193.99.144.71),
r = sd_resolve_getnameinfo(resolve, q2, (struct sockaddr*) sa,
sizeof(sa), 0, true, true);
if (r 0)
log_error(sd_resolve_getnameinfo(): %s\n, strerror(-r));
@@ -90,15 +94,11 @@ int main(int argc, char *argv[]) {
struct addrinfo *i;
for (i = ai; i; i = i-ai_next) {
-char t[256];
-const char *p = NULL;
+_cleanup_free_ char *addr = NULL;
-if (i-ai_family == PF_INET)
-p = inet_ntop(AF_INET, ((struct sockaddr_in*)
i-ai_addr)-sin_addr, t, sizeof(t));
-else if (i-ai_family == PF_INET6)
-p = inet_ntop(AF_INET6, ((struct
sockaddr_in6*) i-ai_addr)-sin6_addr, t, sizeof(t));
+assert_se(sockaddr_pretty(i-ai_addr, i-ai_addrlen,
false, addr) == 0);
-printf(%s\n, p);
+puts(addr);
}
printf(canonical name: %s\n, strna(ai-ai_canonname));
@@ -109,7 +109,7 @@ int main(int argc, char *argv[]) {
if (r)
log_error(error: %s %i\n, gai_strerror(r), r);
else
-printf(%s -- %s\n, host, serv);
+printf(Host: %s -- Serv: %s\n, host, serv);
/* Interpret the result of the SRV lookup */
r = sd_resolve_res_done(q3, srv);
@@ -118,9 +118,7 @@ int main(int argc, char *argv[]) {
else if (r == 0)
log_error(No reply for SRV lookup\n);
else {
-int qdcount;
-int ancount;
-int len;
+int qdcount, ancount, len;
const unsigned char *pos = srv + sizeof(HEADER);
unsigned char *end = srv + r;
HEADER *head = (HEADER *)srv;
@@ -157,7 +155,5 @@ int main(int argc, char *argv[]) {
}
}
-r = 0;
-
-return r;
+return 0;
}
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
Thanks Michael for answering, :) On 26 March 2014 18:59, Michael Biebl mbi...@gmail.com wrote: 2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com: If your daemon is not functional if the hardware is not present, I'd probably start it via a udev rule and SYSTEMD_WANTS. Do you have an example for this please? I don't quite understand why I can't I just name the device in the service file. Why does it have to be so confusing. Still don't understand the need for escaping... is there a need? Thank you, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On 03/26/2014 01:50 PM, Kai Hendry wrote:
Thanks Michael for answering, :)
On 26 March 2014 18:59, Michael Biebl mbi...@gmail.com wrote:
2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com:
If your daemon is not functional if the hardware is not present, I'd
probably start it via a udev rule and SYSTEMD_WANTS.
Do you have an example for this please?
I don't quite understand why I can't I just name the device in the
service file. Why does it have to be so confusing. Still don't
understand the need for escaping... is there a need?
The reason is when your hardware becomes available you activate the
service.
My udev foo is a bit rusty but you can try something along the lines of...
/etc/udev/rules.d/98-shk-local.rules
SUBSYSTEM==input, ENV{ID_INPUT_KEYBOARD}==?*,
ENV{.INPUT_CLASS}=kbd, TAG+=systemd,
ENV{SYSTEMD_WANTS}+=shkd@%p.service
/etc/systemd/system/shkd@.service
[Unit]
Description=Simple HotKey Daemon
[Service]
ExecStart=/usr/local/bin/shkd %I
Restart=always
[Install]
WantedBy=multi-user.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On 2014-03-26 14:50, Kai Hendry wrote: Thanks Michael for answering, :) On 26 March 2014 18:59, Michael Biebl mbi...@gmail.com wrote: 2014-03-26 3:56 GMT+01:00 Kai Hendry hen...@webconverger.com: If your daemon is not functional if the hardware is not present, I'd probably start it via a udev rule and SYSTEMD_WANTS. Do you have an example for this please? I don't quite understand why I can't I just name the device in the service file. Why does it have to be so confusing. Still don't understand the need for escaping... is there a need? While Jóhann has answered the technical part of your question, I'd like to address the quoting part: in the various configuration locations you were talking about earlier, quoting of filenames is required as these config directives can take a wide range of arguments that can reference many other things beside devices. Since those units are all defined in files, whose names are the unit name, all those names have to be valid file names. So a unit can also Requires=foo.service, which will be defined in a file called foo.service. The specifics are described in http://www.freedesktop.org/software/systemd/man/systemd.unit.html: Some unit names reflect paths existing in the file system namespace. Example: a device unit dev-sda.device refers to a device with the device node /dev/sda in the file system namespace. If this applies, a special way to escape the path name is used, so that the result is usable as part of a filename. Basically, given a path, / is replaced by -, and all unprintable characters and the - are replaced by C-style \x20 escapes. The root directory / is encoded as single dash, while otherwise the initial and ending / is removed from all paths during transformation. This escaping is reversible. Regards, David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Add hwdb entry for Samsung Series 7 Ultra.
Add hwdb entry for Samsung Series 7 Ultra. --- hwdb/60-keyboard.hwdb | 8 1 file changed, 8 insertions(+) diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb index bd8fd10..832c686 100644 --- a/hwdb/60-keyboard.hwdb +++ b/hwdb/60-keyboard.hwdb @@ -924,6 +924,14 @@ keyboard:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pn*90X3A*:pvr* KEYBOARD_KEY_96=!kbdillumup# Fn+F8 keyboard backlight up KEYBOARD_KEY_d5=!wlan # Fn+F12 Wi-Fi toggle +# Series 7 Ultra +keyboard:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pn*7[34]0U3E*:pvr* + KEYBOARD_KEY_ce=!prog1 # Fn+F1 launch settings + KEYBOARD_KEY_97=!kbdillumdown # Fn+F9 keyboard backlight down + KEYBOARD_KEY_96=!kbdillumup# Fn+F10 keyboard backlight up + KEYBOARD_KEY_b3=!prog3 # Fn+F11 fan/cooling mode changer + KEYBOARD_KEY_d5=!wlan # Fn+F12 wlan/airplane switch + # SQ1US keyboard:dmi:bvn*:bvr*:bd*:svn[sS][aA][mM][sS][uU][nN][gG]*:pnSQ1US:pvr* KEYBOARD_KEY_d4=menu -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add hwdb entry for Samsung Series 7 Ultra.
On Wed, Mar 26, 2014 at 06:48:13PM -0700, Scott Thrasher wrote: Add hwdb entry for Samsung Series 7 Ultra. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] simple way to crash systemd via a dangling symlink
There is an interesting bug which can be used to crash systemd via a dangling symlink. For details please see [0]. To trigger the bug, you need a socket activated service. I'm using cups in this case. The steps to reproduce are a/ Make sure cups.socket is properly configured and in state active (listening) b/ Make sure cups.service is *not* running c/ Create /etc/systemd/system/cups.socket.conf.d/ and then a dangling symlink like this ln -s /nonexistent /etc/systemd/system/cups.socket.conf.d/foo.conf d/ Run systemctl daemon-reload The socket is now in this state: Active: active (listening) Loaded: error (Reason: No such file or directory) e/ Now trigger a request on the cups.socket, e.g. using lpq → systemd freezes The problem afaics is triggered in src/core/socket.c: socket_enter_running(), when the incoming request causes the start of the corresponding service unit via r = manager_add_job(UNIT(s)-manager, JOB_START, UNIT_DEREF(s-service), JOB_REPLACE, true, error, NULL); I think after the socket configuration has been messed up and the daemon-reload, UNIT_DEREF(s-service) does no longer point to a valid unit, and so the assert in manager_add_job() kicks in. I tested this with 204 and 208, and both versions are affected. Any suggestions how to fix this? A few remarks 1/ A dangling drop-in snippet should imho *not* cause the unit Load state to be Loaded: error (Reason: No such file or directory) 2/ If a socket is in such a state, we probably shouldn't process incoming requests and try to start the service 3/ Should we stop the socket if the Load state is error Michael [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742322#58 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
