Re: [systemd-devel] [PATCH v2] sd-rtnl: fix off-by-one
On Mon, Mar 31, 2014 at 6:20 AM, Steven Siloti ssil...@gmail.com wrote:
Also fix type parameter passed to new0
Thanks to both. Applied.
Cheers,
Tom
src/libsystemd/sd-rtnl/rtnl-message.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 5265184..4ace94c 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -911,11 +911,11 @@ int rtnl_message_parse(sd_rtnl_message *m,
unsigned short type;
size_t *tb;
-tb = (size_t *) new0(size_t *, max);
+tb = new0(size_t, max + 1);
if(!tb)
return -ENOMEM;
-*rta_tb_size = max;
+*rta_tb_size = max + 1;
for (; RTA_OK(rta, rt_len); rta = RTA_NEXT(rta, rt_len)) {
type = rta-rta_type;
--
1.9.1
___
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] [212] systemd-networkd crashes with simple network config
On Mon, Mar 31, 2014 at 12:28 AM, Tom Gundersen t...@jklm.no wrote: On Sun, Mar 30, 2014 at 10:18 PM, Kai Krakow hurikha...@gmail.com wrote: Tom Gundersen t...@jklm.no schrieb: On Sun, Mar 30, 2014 at 6:07 PM, Kai Krakow hurikha...@gmail.com wrote: Tom Gundersen t...@jklm.no schrieb: Starting it from command line shows: # /usr/lib/systemd/systemd-networkd enp4s0: link is up enp4s0: carrier on segmentation fault (core dumped) If you could reproduce this with debug symbols included, that would be very helpful (I cannot reproduce it here). I managed to get at least this backtrace. Somehow gdb did not autoload the symbols for systemd from /usr/lib/debug/usr/lib/systemd... It is probably more helpful now (at least I hope). #0 0x003c49a82a7d in __libc_calloc (n=optimized out, elem_size=optimized out) at malloc.c:3172 av = 0x3c49da9640 main_arena oldtop = 0x6884d0 p = optimized out bytes = 88 sz = 88 csz = optimized out oldtopsize = 23344 mem = 0x6715f0 clearsize = optimized out nclears = optimized out d = optimized out hook = optimized out __func__ = __libc_calloc Hm, so the segfault happens in glibc... It is triggered by us calling calloc(1, 88), which I think is a supported thing to do ;) At least as far as I can tell this is not a bug on our side... BTW: It works when running through valgrind: ==6041== Memcheck, a memory error detector ==6041== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==6041== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6041== Command: /usr/lib/systemd/systemd-networkd ==6041== ==6041== Conditional jump or move depends on uninitialised value(s) ==6041==at 0x3C49617AB6: index (strchr.S:55) ==6041==by 0x3C49607A12: expand_dynamic_string_token (dl-load.c:431) ==6041==by 0x3C49608304: _dl_map_object (dl-load.c:2299) ==6041==by 0x3C4960181D: map_doit (rtld.c:626) ==6041==by 0x3C4960E985: _dl_catch_error (dl-error.c:177) ==6041==by 0x3C496010EF: do_preload (rtld.c:815) ==6041==by 0x3C496039D7: dl_main (rtld.c:1629) ==6041==by 0x3C496152B7: _dl_sysdep_start (dl-sysdep.c:241) ==6041==by 0x3C49604E94: _dl_start (rtld.c:331) ==6041==by 0x3C49601637: ??? (in /lib64/ld-2.17.so) ==6041== ==6041== Conditional jump or move depends on uninitialised value(s) ==6041==at 0x3C49617ABB: index (strchr.S:58) ==6041==by 0x3C49607A12: expand_dynamic_string_token (dl-load.c:431) ==6041==by 0x3C49608304: _dl_map_object (dl-load.c:2299) ==6041==by 0x3C4960181D: map_doit (rtld.c:626) ==6041==by 0x3C4960E985: _dl_catch_error (dl-error.c:177) ==6041==by 0x3C496010EF: do_preload (rtld.c:815) ==6041==by 0x3C496039D7: dl_main (rtld.c:1629) ==6041==by 0x3C496152B7: _dl_sysdep_start (dl-sysdep.c:241) ==6041==by 0x3C49604E94: _dl_start (rtld.c:331) ==6041==by 0x3C49601637: ??? (in /lib64/ld-2.17.so) ==6041== ==6041== Invalid read of size 8 ==6041==at 0x40C617: rtnl_message_parse (rtnl-message.c:1090) ==6041==by 0x40CB11: sd_rtnl_message_rewind (rtnl-message.c:1276) ==6041==by 0x40CDA4: socket_read_message (rtnl-message.c:1213) ==6041==by 0x417DE1: sd_rtnl_process (sd-rtnl.c:274) ==6041==by 0x4180C2: io_callback (sd-rtnl.c:764) ==6041==by 0x415C9D: source_dispatch (sd-event.c:1943) ==6041==by 0x416500: sd_event_run (sd-event.c:2225) ==6041==by 0x416A47: sd_event_loop (sd-event.c:2244) ==6041==by 0x40401B: main (networkd.c:108) ==6041== Address 0x4cd28e8 is 0 bytes after a block of size 264 alloc'd ==6041==at 0x4A07462: calloc (vg_replace_malloc.c:593) ==6041==by 0x40C59E: rtnl_message_parse (rtnl-message.c:1076) ==6041==by 0x40CB11: sd_rtnl_message_rewind (rtnl-message.c:1276) ==6041==by 0x40CDA4: socket_read_message (rtnl-message.c:1213) ==6041==by 0x417DE1: sd_rtnl_process (sd-rtnl.c:274) ==6041==by 0x4180C2: io_callback (sd-rtnl.c:764) ==6041==by 0x415C9D: source_dispatch (sd-event.c:1943) ==6041==by 0x416500: sd_event_run (sd-event.c:2225) ==6041==by 0x416A47: sd_event_loop (sd-event.c:2244) ==6041==by 0x40401B: main (networkd.c:108) ==6041== ==6041== Invalid write of size 8 ==6041==at 0x40C62E: rtnl_message_parse (rtnl-message.c:1093) ==6041==by 0x40CB11: sd_rtnl_message_rewind (rtnl-message.c:1276) ==6041==by 0x40CDA4: socket_read_message (rtnl-message.c:1213) ==6041==by 0x417DE1: sd_rtnl_process (sd-rtnl.c:274) ==6041==by 0x4180C2: io_callback (sd-rtnl.c:764) ==6041==by 0x415C9D: source_dispatch (sd-event.c:1943) ==6041==by 0x416500: sd_event_run (sd-event.c:2225) ==6041==by 0x416A47: sd_event_loop (sd-event.c:2244) ==6041==by 0x40401B: main (networkd.c:108) ==6041== Address 0x4cd28e8 is 0 bytes after a block of size 264 alloc'd ==6041==at 0x4A07462: calloc
[systemd-devel] [PATCH] doc: fix items' names in PORTING-DBUS1
--- src/libsystemd/sd-bus/PORTING-DBUS1 | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/libsystemd/sd-bus/PORTING-DBUS1 b/src/libsystemd/sd-bus/PORTING-DBUS1 index 0253a42..f2ebcd7 100644 --- a/src/libsystemd/sd-bus/PORTING-DBUS1 +++ b/src/libsystemd/sd-bus/PORTING-DBUS1 @@ -123,8 +123,8 @@ at the same time! This pretty much explains the ioctl header. The actual payload of the data is now referenced in additional items that are attached to this ioctl header structure at the end. When sending a message, you attach -items of the type PAYLOAD_VEC, PAYLOAD_MEMFD, FDS, BLOOM, DST_NAME to -it: +items of the type PAYLOAD_VEC, PAYLOAD_MEMFD, FDS, BLOOM_FILTER, +DST_NAME to it: KDBUS_ITEM_PAYLOAD_VEC: contains a pointer + length pair for referencing arbitrary user memory. This is how you reference most @@ -134,15 +134,15 @@ it: to send prepared memfds (see below) over. This item contains an fd for a memfd plus a size. - KDBUS_ITEM_PAYLOAD_FDS: for sending over fds attach an item of this - type with an array of fds. + KDBUS_ITEM_FDS: for sending over fds attach an item of this type with + an array of fds. - KDBUS_ITEM_BLOOM: the calculated bloom filter of this message, only - for undirected (broadcast) message. + KDBUS_ITEM_BLOOM_FILTER: the calculated bloom filter of this message, + only for undirected (broadcast) message. - KDBUS_DST_NAME: for messages that are directed to a well-known name - (instead of a unique name), this item contains the well-known name - field. + KDBUS_ITEM_DST_NAME: for messages that are directed to a well-known + name (instead of a unique name), this item contains the well-known + name field. A single message may consists of no, one or more payload items of type PAYLOAD_VEC or PAYLOAD_MEMFD. D-Bus protocol implementations should -- 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 2/4] endpoint: protect the idr tree on release
On Mon, Mar 31, 2014 at 2:41 AM, Djalal Harouni tix...@opendz.org wrote: endpoint.c | 2 ++ Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 4/4] connection: unref ep and bus and free match_db on error path
On Mon, Mar 31, 2014 at 2:41 AM, Djalal Harouni tix...@opendz.org wrote: connection.c | 2 +- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] handle: change return value from -EFAULT to -EPERM
On Mon, Mar 31, 2014 at 2:41 AM, Djalal Harouni tix...@opendz.org wrote: Return -EPERM if current does not have the appropriate privileges to create custom endpoints. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] kdbus: use kdbus_conn_find_peer() where appropriate
On Mon, Mar 31, 2014 at 2:43 AM, Djalal Harouni tix...@opendz.org wrote: connection.c | 7 ++- match.c | 14 ++ names.c | 5 + Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd not correctly handle audio device acls for the active session?
'Twas brillig, and Kawing Chiu at 29/03/14 02:13 did gyre and gimble: So, is that simply not achievable in systemd? I mean, since logind has no way to know about my session on vt7, then what about I *tell* it explicitly? Maybe through some cmdline tools, for example, something like: `loginctl add-vt vt7 session03`, or through proper configuration of logind? Or can I just spawn startx in a new session that is associative with vt7, i.e. something like `systemd-setsid startx -- vt7`? As far as I understand it, this is more of a PAM problem than a systemd one. The problem would be starting a second session from within an initial one. All in all, it would be possible to hack something up that still switched VTs and did all the necessary stuff but it would be a bit of a pain to do. e.g. you could have startx do soemthing like: 1. Write a one-time config for gdm/kdm/whatever to trigger an autologin by a given user. 2. Start a new display server (gdm/kdm/whatever) and let it pick the next available vt (or favour vt7 onwards although the whole vt7 is graphics thing is not really true these days - most folks start on vt1 these days). Perhaps this is done simply by starting x@7.service or some similar templated unit) 3. Let the display server pick up the autologin config and log you in, registering a new session (which will be active). 4. Cleanup the autologin config after it's been used. 5. Wait for the X server to exit. 6. Switch back to the original VT. All in all, this is a pretty messy and not easy to configure and also needs privileges to run so isn't nice from a security perspective. All in all it's just easier to do the whole reuse the current vt thing instead. 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
[systemd-devel] git requires now linux api userspace headers = 3.13 to build?
User reported me today, http://bpaste.net/show/195803/ IFLA_VLAN_PROTOCOL is not defined before 3.12, but even with 3.12 there are different errors, so at least = 3.13 is now required snip /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:10: error: 'IFLA_VLAN_PROTOCOL' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:9: error: array index in initializer not of integer type /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:9: error: (near initialization for 'rtnl_link_info_data_vlan_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:69:52: error: 'IFLA_BOND_MAX' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:10: error: 'IFLA_BOND_MODE' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: array index in initializer not of integer type /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: field name not in record or union initializer /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:10: error: 'IFLA_BOND_ACTIVE_SLAVE' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: array index in initializer not of integer type /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: field name not in record or union initializer /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:69:21: warning: 'rtnl_link_info_data_bond_types' defined but not used [-Wunused-variable] make[2]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo] Error 1 /snip I remember reading a while back here = 3.7 being required and that being reworked to not require so new, but looks like something backfired there... - Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] git requires now linux api userspace headers = 3.13 to build?
On Mon, Mar 31, 2014 at 5:08 PM, Samuli Suominen ssuomi...@gentoo.org wrote: User reported me today, http://bpaste.net/show/195803/ IFLA_VLAN_PROTOCOL is not defined before 3.12, but even with 3.12 there are different errors, so at least = 3.13 is now required snip /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:10: error: 'IFLA_VLAN_PROTOCOL' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:9: error: array index in initializer not of integer type /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:66:9: error: (near initialization for 'rtnl_link_info_data_vlan_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:69:52: error: 'IFLA_BOND_MAX' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:10: error: 'IFLA_BOND_MODE' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: array index in initializer not of integer type /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: field name not in record or union initializer /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:70:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:10: error: 'IFLA_BOND_ACTIVE_SLAVE' undeclared here (not in a function) /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: array index in initializer not of integer type /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: field name not in record or union initializer /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:71:9: error: (near initialization for 'rtnl_link_info_data_bond_types') /var/tmp/portage/sys-apps/systemd-/work/systemd-/src/libsystemd/sd-rtnl/rtnl-types.c:69:21: warning: 'rtnl_link_info_data_bond_types' defined but not used [-Wunused-variable] make[2]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo] Error 1 /snip I remember reading a while back here = 3.7 being required and that being reworked to not require so new, but looks like something backfired there... Ah, my bad. I did the rework, but forgot to put in the #ifdef's. Will do. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Revisiting the ExecRestart issue
On Sat, Mar 29, 2014 at 9:09 PM, Michael Scherer m...@zarb.org wrote: Le vendredi 28 mars 2014 à 12:12 -0500, Brandon Black a écrit : 4) Socket Activation! I know this is what some will scream when they skim the above, but it's not a realistic solution in this case for a few reasons: a) The startup delay, in some cases, can be many whole wallclock seconds. This is necessary and acceptable in the general sense (this is network service that people use with large server-side installations, not a desktop thing). It only occurs on the first start, no ? No, these delays (well, for configurations large enough to involve substantial delays) will happen on every fresh start, include restart starts. This means the sequential stop-start that systemd wants to do is always going to give an availability gap where no daemon is processing requests for a while. Socket activation would keep the sockets open during that window, but the buffers would just overflow anyways and/or the eventual responses would be way too late to matter. The command I want to execute for ExecRestart doesn't have this issue because it knows how to coordinate with itself for overlapping, so that the expensive start operations happen before stop. socket label that could be accessed by the daemon via sd_* APIs to distinguish would be useful here? You can use getsockopt to get some information, and match the port/type to the appropriate structure. See https://trac.torproject.org/projects/tor/ticket/8908 for a patch doing that kind of thing for tor. What I was trying to say (perhaps very unclearly): there might be distinctions between the many sockets which getsockname() does not capture. For a generic example: the daemon may allow the user to configure 0-N TCP sockets for HTTP and 0-M other TCP sockets for HTTPS. The user gets to choose arbitrary port numbers for them all. getsockname() is going to show me M+N TCP sockets on arbitrary ports, but how does the information about which was meant for which role get from user - service unit - actual daemon code? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tests: fix test-rtnl-manual.c compile failure
Needs KMOD_CFLAGS --- Makefile.am | 4 1 file changed, 4 insertions(+) diff --git a/Makefile.am b/Makefile.am index 6c7d6e5..77495a4 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1399,6 +1399,10 @@ test_ipcrm_LDADD = \ libsystemd-shared.la \ -lrt +test_rtnl_manual_CFLAGS = \ + $(AM_CFLAGS) \ + $(KMOD_CFLAGS) + test_rtnl_manual_SOURCES = \ src/test/test-rtnl-manual.c -- 1.8.4.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option
Several units now utilize the PrivateNetwork parameter, which requires network namespace support. --- README | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README b/README index fc13e10..cecbcbf 100644 --- a/README +++ b/README @@ -70,6 +70,9 @@ REQUIREMENTS: create additional symlinks in /dev/disk/ and /dev/tape: CONFIG_BLK_DEV_BSG +Required for PrivateNetwork in service units: + CONFIG_NET_NS + Optional but strongly recommended: CONFIG_IPV6 CONFIG_AUTOFS4_FS -- 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
On 31 March 2014 09:54, Kai Hendry hen...@webconverger.com wrote:
Not sure what to try next? If I start it manually `sudo systemctl
start shkd@-dev-input-event0.service`, it starts working again. Is
http://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutSec=
the right way to proceed? Not sure.
RestartSec=5 did the trick! Not sure why systemd gives up trying to
restart a process, despite Restart=always
http://ix.io/bog
Sidenote: Even though my /etc/udev/rules.d/98-shk-local.rules has
ENV{SYSTEMD_WANTS}+=shkd@%N.service, how come
shkd@sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2.2-1\x2d1.2.2:1.0-input-input0.service
shkd@sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2.2-1\x2d1.2.2:1.0-input-input2.service
show up?? These are sys devices (%p) not %N ($devnode).
Still don't understand where
[hendry@alarmpi ~]$ systemctl status
shkd@sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2.2-1\x2d1.2.2:1.0-input-input1.service
shkd@sys-devices-platform-bcm2708_usb-usb1-1x2d1-1x2d1.2-1x2d1.2.2-1x2d1.2.2:1.0-input-input1.service
- Simple HotKey Daemon
Loaded: loaded (/etc/systemd/system/shkd@.service; disabled)
Active: inactive (dead)
Comes from.
Kind regards,
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
