[systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)
My container is degraded because systemd-tmpfiles-setup.service failed. My understanding is that it should not run in the container anyway. (Right?) How do I find out why it was started? This is probably a noob question. Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] loginctl: add rule for qemu's pci-bridge-seat
On Mi, 2015-07-01 at 13:10 +0200, David Herrmann wrote:
Hi
On Mon, Jun 29, 2015 at 9:42 AM, Gerd Hoffmann kra...@redhat.com wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/login/71-seat.rules.in | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/login/71-seat.rules.in b/src/login/71-seat.rules.in
index ab7b66f..270da71 100644
--- a/src/login/71-seat.rules.in
+++ b/src/login/71-seat.rules.in
@@ -17,6 +17,12 @@ SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
# 'Plugable' USB hub, sound, network, graphics adapter
SUBSYSTEM==usb, ATTR{idVendor}==2230, ATTR{idProduct}==000[13],
ENV{ID_AUTOSEAT}=1
+# qemu (version 2.4+) has a PCI-PCI bridge (-device pci-bridge-seat)
+# to group devices belonging to one seat.
+# see http://git.qemu.org/?p=qemu.git;a=blob;f=docs/multiseat.txt
+SUBSYSTEM==pci, ATTR{vendor}==0x1b36, ATTR{device}==0x000a, \
+ TAG+=seat, ENV{ID_AUTOSEAT}=1
+
I have no idea why this is correct. Could you provide a proper commit-message?
Is this specific VID/PID match exclusively used for seat'ing?
Yes. The normal pci-pci bridge (-device pci-bridge) has 1b36:0001.
The new pci-bridge-seat was specifically added to simplify guest-side
multiseat configuration. It is identical to the normal pci-pci bridge,
except that it has a different id (1b36:000a) so we can match it and
configure multiseating automatically.
The documentation linked in the comment has all the details. /me
through this would be more useful as it is visible on the installed
system (unlike the git commit message).
But I can cut paste the paragraph above into the commit message and
resend. Or should I redo the github pull-request instead?
cheers,
Gerd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [solved] howto handle one time shutdown programs
On Wed, Jul 1, 2015 at 2:30 PM, Andreas Buschmann busch...@tech.net.de wrote: Hello Andrei, On Tue 30-Jun-2015 15:45 CEST Andrei Borzenkov writes: 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. It works. But only if everything you need is in the root filesystem. It would be helpful if the man page for man systemd-shutdown would be extended by: --- The executables in /usr/lib/systemd/system-shutdown only have access to the root filesystem (/). All other filesystems are not mounted any more. The remaining mounts are: /proc /sys /dev For debugging these scripts redirect your output to /dev/ttyS0 or /dev/ttyS1 and log that output over a serial console switch. --- Well, a paragraph before contains: Before shutting down, this binary will try to unmount all remaining file systems, disable all remaining swap devices, detach all remaining storage devices and kill all remaining processes.. But if you think it is not clear enough, submit pull request (or at least patch here :) ) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-tmpfiles for the user instance of systemd
On Wednesday 01 of July 2015 12:00:59 Dimitri John Ledkov wrote: Heya, Hello, thank for the reply. On 1 July 2015 at 11:35, Daniel Tihelka dtihe...@gmail.com wrote: Hello, does anyone have an experience with the use of systemd-tmpfiles for the user instance of systemd. My question would be - what sort of files are you creating with tmpfiles? Well, my intention was mostly put it on my directory, where I use to store some temporary results and data, and where there is currently a several GB mess :-) The task of systemd-tmpfiles tool would mostly be to prone files older than, let say 5 months (I know that all important data must be copied from the dir ...). And possibly also a downloads dir, chrome cache and stuff like that. Sure, it could be achieved by a find-embedding script as well, but if there is this systemd-tmpfiles which I do not have to tune and check if it is working correctly (which may be harder on several-months scale ...) system stuff is known to use dynamic directories in /var /run and similar and it all used to be created ad-hoc in either packaging or the init scripts. User stuff on the other hand, generally works with untouched home directories as they typically are not allowed to be modified by typical packaging systems. Hence most of the user things handle creation of the dirs they need themself and do it gracefully enough. Agree. Well, I know that my usage of systemd-tmpfiles is not that it was primarily designed to, but its capabilities match my intention quiet well, I think (except the few config-related inconsistencies I mentioned). Thank you again, DT signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-tmpfiles for the user instance of systemd
Hello, does anyone have an experience with the use of systemd-tmpfiles for the user instance of systemd. I ended with the following files (all copied from system service definitions and adjusted): * systemd-tmpfiles-setup.service: [Unit] DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/systemd-tmpfiles --create --remove --root=%h %h/.config/tmpfiles.conf [Install] WantedBy=default.target * systemd-tmpfiles-clean.service: [Unit] DefaultDependencies=no [Service] Type=oneshot ExecStart=/usr/bin/systemd-tmpfiles --clean --root=%h %h/.config/tmpfiles.conf IOSchedulingClass=idle * systemd-tmpfiles-clean.timer [Unit] Description= [Timer] OnUnitActiveSec=1d [Install] WantedBy=default.target Well, it work, at least. What I have found is that: * man mentions that CAP_ADMIN is required to prevent bump of access time on directories, which may prevent their removal. It is OK for me, if it is valid for dirs only * I have to specify the config file manually (i.e. %h/.config/tmpfiles.conf). There is no attempt to search for e.g. ~/.config/tmpfiles.d/ or /etc/tmpfiles.d/user/ directories when running in user mode. Is that correct? * I have either use full paths in the config file (e.g. d /home/me/...) or to use --root switch (where still the paths in config must start with /). I suppose that the config file/s does/do not support %h specifier or something like this. I just want to ask, since I do not want to make the stuff more complicated than necessary. So I am all ears if if you know how to simplify/generalize the configuration Thank you, Dan T, P.S. systemctl --version systemd 219 +PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN on Arch Linux. signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] loginctl: add rule for qemu's pci-bridge-seat
Hi
On Mon, Jun 29, 2015 at 9:42 AM, Gerd Hoffmann kra...@redhat.com wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/login/71-seat.rules.in | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/login/71-seat.rules.in b/src/login/71-seat.rules.in
index ab7b66f..270da71 100644
--- a/src/login/71-seat.rules.in
+++ b/src/login/71-seat.rules.in
@@ -17,6 +17,12 @@ SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
# 'Plugable' USB hub, sound, network, graphics adapter
SUBSYSTEM==usb, ATTR{idVendor}==2230, ATTR{idProduct}==000[13],
ENV{ID_AUTOSEAT}=1
+# qemu (version 2.4+) has a PCI-PCI bridge (-device pci-bridge-seat)
+# to group devices belonging to one seat.
+# see http://git.qemu.org/?p=qemu.git;a=blob;f=docs/multiseat.txt
+SUBSYSTEM==pci, ATTR{vendor}==0x1b36, ATTR{device}==0x000a, \
+ TAG+=seat, ENV{ID_AUTOSEAT}=1
+
I have no idea why this is correct. Could you provide a proper commit-message?
Is this specific VID/PID match exclusively used for seat'ing? Or might
other pci-bridges use the same (without any intention to get different
seats?). Even if that's the case, I'm still fine with you default, but
please describe this properly so we can understand the implications
later on.
Thanks!
David
# Mimo 720, with integrated USB hub, displaylink graphics, and e2i
# touchscreen. This device carries no proper VID/PID in the USB hub,
# but it does carry good ID data in the graphics component, hence we
--
1.8.3.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] systemd-tmpfiles for the user instance of systemd
Heya, On 1 July 2015 at 11:35, Daniel Tihelka dtihe...@gmail.com wrote: Hello, does anyone have an experience with the use of systemd-tmpfiles for the user instance of systemd. My question would be - what sort of files are you creating with tmpfiles? system stuff is known to use dynamic directories in /var /run and similar and it all used to be created ad-hoc in either packaging or the init scripts. User stuff on the other hand, generally works with untouched home directories as they typically are not allowed to be modified by typical packaging systems. Hence most of the user things handle creation of the dirs they need themself and do it gracefully enough. -- Regards, Dimitri. Pura Vida! https://clearlinux.org Open Source Technology Center Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [solved] howto handle one time shutdown programs
Hello Andrei, On Tue 30-Jun-2015 15:45 CEST Andrei Borzenkov writes: 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. It works. But only if everything you need is in the root filesystem. It would be helpful if the man page for man systemd-shutdown would be extended by: --- The executables in /usr/lib/systemd/system-shutdown only have access to the root filesystem (/). All other filesystems are not mounted any more. The remaining mounts are: /proc /sys /dev For debugging these scripts redirect your output to /dev/ttyS0 or /dev/ttyS1 and log that output over a serial console switch. --- Mit freundlichen Gruessen Andreas Buschmann -- 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
Re: [systemd-devel] [PATCH] loginctl: add rule for qemu's pci-bridge-seat
Hi
On Wed, Jul 1, 2015 at 4:25 PM, Gerd Hoffmann kra...@redhat.com wrote:
On Mi, 2015-07-01 at 13:10 +0200, David Herrmann wrote:
Hi
On Mon, Jun 29, 2015 at 9:42 AM, Gerd Hoffmann kra...@redhat.com wrote:
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/login/71-seat.rules.in | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/login/71-seat.rules.in b/src/login/71-seat.rules.in
index ab7b66f..270da71 100644
--- a/src/login/71-seat.rules.in
+++ b/src/login/71-seat.rules.in
@@ -17,6 +17,12 @@ SUBSYSTEM==usb, ATTR{bDeviceClass}==09, TAG+=seat
# 'Plugable' USB hub, sound, network, graphics adapter
SUBSYSTEM==usb, ATTR{idVendor}==2230, ATTR{idProduct}==000[13],
ENV{ID_AUTOSEAT}=1
+# qemu (version 2.4+) has a PCI-PCI bridge (-device pci-bridge-seat)
+# to group devices belonging to one seat.
+# see http://git.qemu.org/?p=qemu.git;a=blob;f=docs/multiseat.txt
+SUBSYSTEM==pci, ATTR{vendor}==0x1b36, ATTR{device}==0x000a, \
+ TAG+=seat, ENV{ID_AUTOSEAT}=1
+
I have no idea why this is correct. Could you provide a proper
commit-message?
Is this specific VID/PID match exclusively used for seat'ing?
Yes. The normal pci-pci bridge (-device pci-bridge) has 1b36:0001.
The new pci-bridge-seat was specifically added to simplify guest-side
multiseat configuration. It is identical to the normal pci-pci bridge,
except that it has a different id (1b36:000a) so we can match it and
configure multiseating automatically.
Ok, then this looks fine.
The documentation linked in the comment has all the details. /me
through this would be more useful as it is visible on the installed
system (unlike the git commit message).
But I can cut paste the paragraph above into the commit message and
resend. Or should I redo the github pull-request instead?
I can amend this information.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] loginctl: add rule for qemu's pci-bridge-seat
Hi, But I can cut paste the paragraph above into the commit message and resend. Or should I redo the github pull-request instead? I can amend this information. Great. thanks, Gerd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Testing kdbus and bus-proxy
Hi, I been testing kdbus (v4.1 branch) and bus-proxy on kernel v4.1 (arch linux) and i just came across an inconsistency with my plain laptop/desktop setup. dleyna crashes as i start gnome-calendar. Also calendar doesn't seem to run aswell, im not able to check my entries (Not sure what's causing that) However, all of that works on dbus-daemon. Let me know if i can provide additional information. jul 01 21:59:09 dbuch-laptop systemd[908]: Started DBUS1: com.intel.dleyna-renderer. jul 01 21:59:09 dbuch-laptop dleyna-renderer-service[1841]: Calling GetRenderers method jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Type[0] Level[0x13] Mask[0x4C] Flags[0x4F] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Load file [/home/dbuch/.config/dleyna-server-service.conf] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: [General settings] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Never Quit: F jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Connector Name: dbus jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Port: 0 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Push host port: 0 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: [Logging settings] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Log Type : 0 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Log Level: 0x13 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: [Network filtering settings] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Enabled : F jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Entries: (null) jul 01 21:59:09 dbuch-laptop systemd[908]: Started DBUS1: com.intel.dleyna-server. jul 01 21:59:09 dbuch-laptop bijiben-shell-search-provider[1701]: (bijiben-shell-search-provider:1701): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed jul 01 21:59:09 dbuch-laptop gnome-calendar[1715]: ** (gnome-calendar:1715): WARNING **: Job failed: Operationen blev afbrudt jul 01 21:59:09 dbuch-laptop dleyna-renderer-service[1841]: Client :1.6293 lost jul 01 21:59:09 dbuch-laptop kernel: traps: dleyna-renderer[1841] general protection ip:7fda14301338 sp:7ffcad8a9530 error:0 in libdleyna-renderer-1.0.so.1.0.3[7fda142f7000+17000] jul 01 21:59:09 dbuch-laptop systemd[908]: dbus-com.intel.dleyna-renderer.service: Main process exited, code=dumped, status=11/SEGV jul 01 21:59:09 dbuch-laptop systemd[908]: dbus-com.intel.dleyna-renderer.service: Unit entered failed state. jul 01 21:59:09 dbuch-laptop systemd[908]: dbus-com.intel.dleyna-renderer.service: Failed with result 'core-dump'. jul 01 21:59:09 dbuch-laptop systemd-coredump[1875]: Removed old coredump core.dleyna-renderer.1000.67c7a5ee3ae54363aba018379336bed6.1841.143578074900.lz4. jul 01 21:59:09 dbuch-laptop systemd-coredump[1875]: Process 1841 (dleyna-renderer) of user 1000 dumped core. Stack trace of thread 1841: #0 0x7fda14301338 dlr_device_unsubscribe (libdleyna-renderer-1.0.so.1) #1 0x7fda14307cfa dlr_upnp_unsubscribe (libdleyna-renderer-1.0.so.1) #2 0x7fda14305017 n/a (libdleyna-renderer-1.0.so.1) #3 0x7fda14820b62 n/a (libdleyna-core-1.0.so.4) #4 0x7fda1455890d g_main_context_dispatch (libglib-2.0.so.0) #5 0x7fda14558ce0 n/a (libglib-2.0.so.0) #6 0x7fda14559002 g_main_loop_run (libglib-2.0.so.0) #7 0x7fda14820d3c dleyna_main_loop_start (libdleyna-core-1.0.so.4) #8 0x7fda13d58790 __libc_start_main (libc.so.6) #9 0x004008e9 _start (dleyna-renderer-service) Stack trace of thread 1853: #0 0x7fda13e16e8d poll (libc.so.6) #1 0x7fda14558c7c n/a (libglib-2.0.so.0) #2 0x7fda14559002 g_main_loop_run (libglib-2.0.so.0) #3 0x7fda13a99876 n/a (libgio-2.0.so.0) #4 0x7fda1457f625 n/a (libglib-2.0.so.0) #5 0x7fda140e1354 start_thread (libpthread.so.0) #6 0x7fda13e1fbfd __clone (libc.so.6) Stack trace of thread 1857:
Re: [systemd-devel] Testing kdbus and bus-proxy
Alright, i just updated kdbus branch, and these issues is solved.. ons. 1. jul. 2015 kl. 22.20 skrev Daniel Buch boogiewasth...@gmail.com: Hi, I been testing kdbus (v4.1 branch) and bus-proxy on kernel v4.1 (arch linux) and i just came across an inconsistency with my plain laptop/desktop setup. dleyna crashes as i start gnome-calendar. Also calendar doesn't seem to run aswell, im not able to check my entries (Not sure what's causing that) However, all of that works on dbus-daemon. Let me know if i can provide additional information. jul 01 21:59:09 dbuch-laptop systemd[908]: Started DBUS1: com.intel.dleyna-renderer. jul 01 21:59:09 dbuch-laptop dleyna-renderer-service[1841]: Calling GetRenderers method jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Type[0] Level[0x13] Mask[0x4C] Flags[0x4F] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Load file [/home/dbuch/.config/dleyna-server-service.conf] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: [General settings] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Never Quit: F jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Connector Name: dbus jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Port: 0 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Push host port: 0 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: [Logging settings] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Log Type : 0 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Log Level: 0x13 jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: [Network filtering settings] jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Enabled : F jul 01 21:59:09 dbuch-laptop dleyna-server-service[1854]: Entries: (null) jul 01 21:59:09 dbuch-laptop systemd[908]: Started DBUS1: com.intel.dleyna-server. jul 01 21:59:09 dbuch-laptop bijiben-shell-search-provider[1701]: (bijiben-shell-search-provider:1701): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed jul 01 21:59:09 dbuch-laptop gnome-calendar[1715]: ** (gnome-calendar:1715): WARNING **: Job failed: Operationen blev afbrudt jul 01 21:59:09 dbuch-laptop dleyna-renderer-service[1841]: Client :1.6293 lost jul 01 21:59:09 dbuch-laptop kernel: traps: dleyna-renderer[1841] general protection ip:7fda14301338 sp:7ffcad8a9530 error:0 in libdleyna-renderer-1.0.so.1.0.3[7fda142f7000+17000] jul 01 21:59:09 dbuch-laptop systemd[908]: dbus-com.intel.dleyna-renderer.service: Main process exited, code=dumped, status=11/SEGV jul 01 21:59:09 dbuch-laptop systemd[908]: dbus-com.intel.dleyna-renderer.service: Unit entered failed state. jul 01 21:59:09 dbuch-laptop systemd[908]: dbus-com.intel.dleyna-renderer.service: Failed with result 'core-dump'. jul 01 21:59:09 dbuch-laptop systemd-coredump[1875]: Removed old coredump core.dleyna-renderer.1000.67c7a5ee3ae54363aba018379336bed6.1841.143578074900.lz4. jul 01 21:59:09 dbuch-laptop systemd-coredump[1875]: Process 1841 (dleyna-renderer) of user 1000 dumped core. Stack trace of thread 1841: #0 0x7fda14301338 dlr_device_unsubscribe (libdleyna-renderer-1.0.so.1) #1 0x7fda14307cfa dlr_upnp_unsubscribe (libdleyna-renderer-1.0.so.1) #2 0x7fda14305017 n/a (libdleyna-renderer-1.0.so.1) #3 0x7fda14820b62 n/a (libdleyna-core-1.0.so.4) #4 0x7fda1455890d g_main_context_dispatch (libglib-2.0.so.0) #5 0x7fda14558ce0 n/a (libglib-2.0.so.0) #6 0x7fda14559002 g_main_loop_run (libglib-2.0.so.0) #7 0x7fda14820d3c dleyna_main_loop_start (libdleyna-core-1.0.so.4) #8 0x7fda13d58790 __libc_start_main (libc.so.6) #9 0x004008e9 _start (dleyna-renderer-service) Stack trace of thread 1853: #0 0x7fda13e16e8d poll (libc.so.6) #1 0x7fda14558c7c n/a (libglib-2.0.so.0) #2 0x7fda14559002 g_main_loop_run (libglib-2.0.so.0) #3 0x7fda13a99876 n/a (libgio-2.0.so.0) #4 0x7fda1457f625 n/a (libglib-2.0.so.0) #5
Re: [systemd-devel] Testing kdbus and bus-proxy
Hi On Wed, Jul 1, 2015 at 10:38 PM, Daniel Buch boogiewasth...@gmail.com wrote: Alright, i just updated kdbus branch, and these issues is solved.. We haven't broken ABI for quite some time (and are now committed to the ABI!). But still, thanks for the report! Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)
Hey Martin, thanks, but: My container is degraded because systemd-tmpfiles-setup.service failed. My understanding is that it should not run in the container anyway. (Right?) It should run in a container; its purpose is both necessary, and I don't see why a container would have any difficulty with it. It runs just fine in both system and even unprivileged user containers here. Here is what fails: # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file system This is systemd 221 on Arch in a container straight from the man page, just in case I screwed up my own, but the behavior is the same. # pacstrap -c -d $(pwd)/arch-tree base # systemd-nspawn -bD $(pwd)/arch-tree/ How do I find out why it was started? $ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service ● └─sysinit.target This analyzes the static dependencies (and does indeed solve my problem here, thanks! I had missed the —reverse flag), but I was wondering whether there was something more dynamic that could tell me something like: a.service started, because b.service required it b.service started because user foobar started it systemctl status systemd-tmpfiles-setup.service will say that it's statically enabled, and the list-dependencies says where. I. e. you should have a symlink /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service (could also be in /lib/systemd/, depending on your distro) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)
Hey Johannes, Johannes Ernst [2015-07-01 11:02 -0700]: My container is degraded because systemd-tmpfiles-setup.service failed. My understanding is that it should not run in the container anyway. (Right?) It should run in a container; its purpose is both necessary, and I don't see why a container would have any difficulty with it. It runs just fine in both system and even unprivileged user containers here. How do I find out why it was started? $ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service systemd-tmpfiles-setup.service ● └─sysinit.target systemctl status systemd-tmpfiles-setup.service will say that it's statically enabled, and the list-dependencies says where. I. e. you should have a symlink /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service (could also be in /lib/systemd/, depending on your distro) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)
2015-07-01 22:50 GMT+02:00 Johannes Ernst johannes.er...@gmail.com: Hey Martin, thanks, but: My container is degraded because systemd-tmpfiles-setup.service failed. My understanding is that it should not run in the container anyway. (Right?) It should run in a container; its purpose is both necessary, and I don't see why a container would have any difficulty with it. It runs just fine in both system and even unprivileged user containers here. Here is what fails: # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file system Which packages ships that tmpfiles snippet? This is not coming from systemd itself. -- 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] Fwd: With my layer, Systemd not invoking my application at startup
Vipin Nair wrote on 01/07/15 07:00: Hi All, I am using the yacto style project and I have created a layer (my first layer) and have build it with WindRiver media which uses Systemd for the startup services. As per my application need, I have to create a new user on the final image and change the owner permissions of certain files to the new user. Since I could not get it done on the build machine, I have written the post install script such that it gets executed on the target board during the 1st boot cycle and from within the post install script I am creating the new user and changing the file ownership. And this works. But the only problem I have now is that, even though I register my service with Systemd at pre-install (or postinstall) section (using the systemctl enable command) my service is not getting launched by Systemd during the 1st boot. On subsequent reboots, it invokes my service at boot up. It's hard to say without seeing your actual service (specifically it's [Install] section) as otherwise we cannot tell what data systemctl enable has to work with. However, from the description of your problem I think you're likely trying to solve it the wrong way. systemd comes with two concepts to do what you want. sysusers is a mechanism to initialise system users and can be confirured to run on first boot. It will create your user for you. tmpfiles can create and change ownership of files and directories. It runs on every boot. Dropping in the appropriate configuration snippet for both might be sufficient for your needs and is likely cleaner than using a service. Hope this helps. Col -- Colin Guthrie colin(at)mageia.org 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] changed property value in signal
hi I am new to systemd. I am using systemd 208, libdbus-1-3_1.4.18-1ubuntu1.4_i386.deb I am to monitor unit stop/failure in my application . So I am subscribing to propertiesChanged signal and paring SubState. The propertieschanged message contains a dictionary and invalidated list of properties. But the dictionary is empty(which is supposed to contain new value of changed properties), so i am left with querying new values of the changed property from list of invalidated properties list. - please let me know how do i get new values in the signal msg itself - is this issue fixed.? if yes in which version? which version i need to upgrade - where do i see commit logs/ version history Thanks Prad ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] what does --ephemeral really do on btrfs?
If I run systemd-nspawn with —ephemeral, it creates a new temporary btrfs subvolume, the documentation says. Mine takes an awful long time — blocking IO on the device in the awful long meantime — and I’m puzzled why. Does it perhaps copy (deep? references only?) the entire drive? Should I put the original directory on a separate subvolume, or how can I speed this up? If I just copied the image / directory, this might be faster. Thanks, Johannes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)
On Jul 1, 2015, at 14:59, Michael Biebl mbi...@gmail.com wrote: 2015-07-01 22:50 GMT+02:00 Johannes Ernst johannes.er...@gmail.com mailto:johannes.er...@gmail.com: Hey Martin, thanks, but: My container is degraded because systemd-tmpfiles-setup.service failed. My understanding is that it should not run in the container anyway. (Right?) It should run in a container; its purpose is both necessary, and I don't see why a container would have any difficulty with it. It runs just fine in both system and even unprivileged user containers here. Here is what fails: # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file system Which packages ships that tmpfiles snippet? This is not coming from systemd itself. https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in -- 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
[systemd-devel] Fwd: With my layer, Systemd not invoking my application at startup
Hi All,
I am using the yacto style project and I have created a layer (my first
layer) and have build it with WindRiver media which uses Systemd for the
startup services.
As per my application need, I have to create a new user on the final image
and change the owner permissions of certain files to the new user.
Since I could not get it done on the build machine, I have written the post
install script such that it gets executed on the target board during the
1st boot cycle
and from within the post install script I am creating the new user and
changing the file ownership. And this works.
But the only problem I have now is that, even though I register my service
with Systemd at pre-install (or postinstall) section (using the systemctl
enable command)
my service is not getting launched by Systemd during the 1st boot. On
subsequent reboots, it invokes my service at boot up.
As part of debugging I just modified my postinstall script, such that it
gets executed on the board (i.e without the exit 1) and not executed on
the 1st boot. After that I see that
systemd invokes my service at boot up. So I wonder if Systemd ignores the
services for which post-install is not invoked at build machine ?
Now I am confused on how to solve this problem.
Only 2 approaches comes to my mind :
1) Run the postinstall on the board only (not on 1st boot) - But with this
(i.e running the postinstall section on board) I don't see the new user
creation happening and as a result it fails to change the file ownership.
2) Somehow force systemd to invoke my service at startup (even with
postinstall running during 1st boot) - But I don't know what I have to do
to achieve this.
Here is the brief of my recipe file :
---
DEPENDS += ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
'systemd-systemctl-native', '', d)}
do_install() {
#if systemd configured
install -m 0755 -d ${D}/lib/systemd/system
cp ${WORKDIR}/${MA_BIN_DIR}/my_ser.service ${D}/lib/systemd/system/
}
pkg_preinst_${PN}() {
if [ $IS_SYSTEMD_CONFIGURED = yes ] ; then
systemctl --root=$D enable my_ser.service# Have tried executing it only
on postinstall, but it does not help.
fi
}
pkg_postinst_${PN}() {
if [ $IS_SYSTEMD_CONFIGURED = yes ] ; then
systemctl --root=$D enable ma.service
fi
if [ x$D = x ] ; then
# Create group and user
groupadd test_grp
useradd -r -s /sbin/nologin -g test_grp test_usr
chown test_usr:test_grp /etc/test_folder/*
if [ $IS_SYSTEMD_CONFIGURED = yes ] ; then
if [ $1 == 1 ] || [ $1 = 2 ] ; then # only install and upgrade
scenario, not to exeute on 1st boot
systemctl daemon-reload
systemctl start my_ser.service
fi
else
exit 1
fi
}
I am new to the yacto project and the layer approach. So kindly guide me on
how to resolve this issue.
Also if this is not the right group to get help on this issue, please
suggest about the relevant group.
Thanks
Vipin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Delaying device service creation
On 06/30/2015 07:47 PM, Mantas Mikulėnas wrote: Options: - Configure it as part of ExecStart if possible. I don't see how is this going to help, sorry. - Configure it using a second .service unit (oneshot), and depend on that one. You meant all services that were depending on the device should depend on that second .service ? I so, I would rather avoid that: it seems much cleaner to me to have the device service started once the configuration has been done, ie when the device really ready. Actually my question is rather : does adding dependencies on device services is supported, so I can make it 'appear' only when the service which creates and configures it is completely finished ? - 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. I have to see how to do that and how to set SYSTEMD_READY=1 once configured. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
