Re: [systemd-devel] Question regarding the NotifyAccess parameter
Hello I am using Fedora 19 and systemd in it is 204 I guess. The issue is present in there. The following is whatmy unit file is cat /usr/lib/systemd/system/Myservice.service [Unit] Description=This is a test service [Service] #PIDFile=/var/run/Myservice.pid #ExecStartPre=/tmp/one_start_pre.sh #ExecStartPre=/bin/systemctl stop Myservice ExecStartPost=/tmp/one_start_post.sh #ExecStartPre=/usr/bin/systemctl stop Myservice RemainAfterExit=yes ExecStart=/tmp/one.sh *Restart=on-failure* NotifyAccess=all WatchdogSec=10 User=admin Group=admin [Install] Alias=myservice.services < systemctl output >>> sudo systemctl status Myservice Myservice.service - This is a test service Loaded: loaded (/usr/lib/systemd/system/Myservice.service; disabled) Active: active (running) since Thu 2013-12-05 18:39:36 IST; 1s ago Process: 20968 ExecStartPost=/tmp/one_start_post.sh (code=exited, status=0/SUCCESS) Main PID: 20967 (one.sh) CGroup: name=systemd:/system/Myservice.service ├─*20967* /bin/bash /tmp/one.sh └─20971 sleep 5 After some time I made the watchdog timer fail. sudo systemctl status Myservice Myservice.service - This is a test service Loaded: loaded (/usr/lib/systemd/system/Myservice.service; disabled) Active: active (running) since Thu 2013-12-05 18:40:52 IST; 2s ago Process: 21180 ExecStartPost=/tmp/one_start_post.sh (code=exited, status=0/SUCCESS) Main PID: 21179 (one.sh) CGroup: name=systemd:/system/Myservice.service ├─*20967* /bin/bash /tmp/one.sh ├─21006 /bin/bash /tmp/one.sh ├─21030 /bin/bash /tmp/one.sh ├─21058 /bin/bash /tmp/one.sh ├─21092 /bin/bash /tmp/one.sh ├─21133 /bin/bash /tmp/one.sh ├─21166 sleep 5 ├─21169 sleep 5 ├─21172 sleep 5 ├─21175 sleep 5 ├─21178 sleep 5 ├─21179 /bin/bash /tmp/one.sh ├─21184 sleep 5 └─21191 sleep 5 << $$ ] systemctl --version systemd 204 +PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ Thanks Salil On 26 November 2013 20:27, Hoyer, Marko (ADITG/SW2) wrote: > > >One more issue I observed is - if I specify Restart=on-failure, if > > > watchdog timer expire, it restart the service. But I can see that it > > > create two processes rather than restarting the process. But if I do > > > systemctl restart Myservice , it kills the previous instance of > > > service and start a new service. Any pointers on why it happens so. > > This part has been already reported as a bug in May: > http://lists.freedesktop.org/archives/systemd-devel/2013-May/011030.html > > Best to my knowledge, this has been fixed in systemd 203, 204, or 205 ... > Please note that the link above does not contain the final bug fix. Some > discussions followed which led to the final solution at a certain point. > Follow the threads, you'll find it ... > > > Best regards > > Marko Hoyer > Software Group II (ADITG/SW2) > > Tel. +49 5121 49 6948 > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd unit review requested
When I fired up F20 on one of my laptops here I noticed that inputattach
doesn't work anymore for serial Wacom devices. It used to be started through
udev, but that doesn't work anymore. So moving to a systemd service it is,
but I'd like a review of the changes please.
The goal is to start inputattach for a serial Wacom device if the pnpid
matches a certain set. The old udev rule was:
SUBSYSTEM=="tty|pnp", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf*", \
RUN+="/usr/sbin/modprobe wacom_w8001", \
RUN+="/usr/sbin/inputattach --daemon -w8001 /dev/%k"
the new rule now is:
SUBSYSTEM=="tty|pnp", KERNEL=="ttyS[0-9]*", ATTRS{id}=="WACf*", \
ENV{SYSTEMD_WANTS}="wacom-inputattach@%k.service",TAG+="systemd"
And the matching wacom-inputattach@.service file shows:
[Unit]
Description="Start inputattach for Wacom ISDv4-compatible serial devices"
[Service]
Type=simple
ExecStartPre=/usr/sbin/modprobe wacom_w8001
ExecStart=/usr/bin/inputattach -w8001 /dev/%I
Anything I'm missing, anything I should change?
Also, do I need this in any target, or is dropping this into
/usr/lib/systemd/system/ enough?
Thanks in advance.
Cheers,
Peter
~
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Last question about systemd before my presentation
Today I am giving my presentation about systemd/journald for a not very enthusiastic public. I would like some last answers on a ‘few’ questions. I understood that you could let systemd start-up the services sequential for debugging purposes. How is that done? Is it possible to change the limits dynamically? When I change the service files and do a reload, are the new limits used, without a reboot being needed? One of the problems mentioned is that services can be started only when they are used for the first time. As I understood it, you can make sure that a service is always loaded, so that there is no waiting time the first time it is called. I understood you could deny a service network connection. How is this done? Until no I could not find it. Is it possible to limit the bandwidth a service is allowed to use? When virtual machines are implementd as a service. You need to let the host define the limits per guest I suppose? How do you let a block-device be read-only for a service? Any last tips about what to share? -- Cecil Westerhof Snow B.V. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix usage of kernel-install
Kernel install doesn't need the second argument on his command line when
removing.
This is correctly documented in the man page.
Signed-off-by: Sébastien Luttringer
---
src/kernel-install/kernel-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/kernel-install/kernel-install
b/src/kernel-install/kernel-install
index 9d3e75d..55cdd69 100644
--- a/src/kernel-install/kernel-install
+++ b/src/kernel-install/kernel-install
@@ -23,7 +23,7 @@ usage()
{
echo "Usage:" >&2
echo "$0 add " >&2
-echo "$0 remove " >&2
+echo "$0 remove " >&2
}
dropindirs_sort()
--
Sébastien "Seblu" Luttringer
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cyclic build dependency with D-Bus
On Wed, Dec 4, 2013 at 10:42 PM, Thomas H.P. Andersen wrote: > Does this paragraph in the README still make sense? > > Note that D-Bus can link against libsystemd-login.so, which > results in a cyclic build dependency. To accommodate for > this, please build D-Bus without systemd first, then build > systemd, then rebuild D-Bus with systemd support. We do not build against libdbus anymore, only one test can be compiled to use it. The text can be removed. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] cyclic build dependency with D-Bus
Does this paragraph in the README still make sense? Note that D-Bus can link against libsystemd-login.so, which results in a cyclic build dependency. To accommodate for this, please build D-Bus without systemd first, then build systemd, then rebuild D-Bus with systemd support. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] busname: check the service state instead of the busname state
git send-email is sadly still not working for me. I am pasting the
patch here and attaching it as well.
In busname_trigger_notify the last check uses IS_SET on the
busname's state but compares it to service states.
I assume that the intended logic was to check the service's
state instead.
---
src/core/busname.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/busname.c b/src/core/busname.c
index c452656..0151ee0 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -526,7 +526,7 @@ static void busname_trigger_notify(Unit *u, Unit *other) {
busname_enter_listening(n);
}
-if (IN_SET(n->state,
+if (IN_SET(s->state,
SERVICE_DEAD,
SERVICE_STOP, SERVICE_STOP_SIGTERM, SERVICE_STOP_SIGKILL,
SERVICE_STOP_POST, SERVICE_FINAL_SIGTERM,
SERVICE_FINAL_SIGKILL,
--
1.8.4.2
From 834438292179d8f93fd31d424579318545c1b7b9 Mon Sep 17 00:00:00 2001
From: Thomas Hindoe Paaboel Andersen
Date: Wed, 4 Dec 2013 22:15:56 +0100
Subject: [PATCH] busname: check the service state instead of the busname state
In busname_trigger_notify the last check uses IS_SET on the
busname's state but compares it to service states.
I assume that the inteded logic was to check the service's
state instead.
---
src/core/busname.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/busname.c b/src/core/busname.c
index c452656..0151ee0 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -526,7 +526,7 @@ static void busname_trigger_notify(Unit *u, Unit *other) {
busname_enter_listening(n);
}
-if (IN_SET(n->state,
+if (IN_SET(s->state,
SERVICE_DEAD,
SERVICE_STOP, SERVICE_STOP_SIGTERM, SERVICE_STOP_SIGKILL,
SERVICE_STOP_POST, SERVICE_FINAL_SIGTERM, SERVICE_FINAL_SIGKILL,
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald API, sd_journal_seek_tail()
On Wed, Dec 4, 2013 at 1:17 AM, Sascha Kattelmann wrote: > Whats the status of this bug? I personally think it would be best to: (1) Keep the current behavior of sd_journal_seek_tail() + sd_journal_previous_skip() (2) Update the docs to reflect that usage (3) Fix sd_journal_seek_tail() to set the iterator to just after the last entry (and work properly as new items come in). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [gummiboot] misaligned menu
On Wed, Dec 4, 2013 at 4:26 PM, János Illés wrote: > I did not find a bug tracker for gummiboot, sorry if this is not the > right place for this. > > I would like to report a small cosmetic bug for gummiboot. It looks like this: > http://i.imgur.com/cDRwIwX.jpg [62 kbyte] > > This is laptop with an intel haswell chipset with full hd display. It's probably the firmware, it announces the console only in the upper left area, the rest of the screen is probably dead for the EFI console. I have several machines showing that. It might all be fine in graphics mode, but the gummiboot menu uses the console mode. Not sure if there would be any way to find that out. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [gummiboot] misaligned menu
Hi! I did not find a bug tracker for gummiboot, sorry if this is not the right place for this. I would like to report a small cosmetic bug for gummiboot. It looks like this: http://i.imgur.com/cDRwIwX.jpg [62 kbyte] This is laptop with an intel haswell chipset with full hd display. -- János ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv5] tmpfiles, man: Add xattr support to tmpfiles
This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.
It is done by adding new line of type "t". Such line should contain
attributes in Argument field, using following format:
name=value
All other fields are ignored.
If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.
Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
---
I'm sorry for late reply, but there were some unexpected events which
excluded me from life for a while.
v5:
* fixes for HAVE_XATTR undefined
* use cunescape() instead of strreplace()
* cache result of strv_length()
* fix typo in manpage
v4:
* grammar fix in man
* style fix
v3:
* "may be used" instead of "should be used" in manpage
* use strv_isempty() instead of != NULL
* rework item_set_xattrs() with split_pair()
* remove copy_item_contents()
* use hashmap_replace() instead of removed copy_item_contents()
* use strv_extend() instead of strv_append()
* cleanup
---
man/tmpfiles.d.xml | 26 +-
src/tmpfiles/tmpfiles.c | 216 +---
2 files changed, 225 insertions(+), 17 deletions(-)
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 1c079f6..676eded 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -248,6 +248,21 @@ L/tmp/foobar ----
/dev/null
place of normal path
names.
+
+
+t
+Set extended
+attributes on item. It may be
+used in conjunction with other
+types (only d, D, f, F, L, p, c, b, z
+makes sense). If used as a standalone
+line, then systemd-tmpfiles
+ will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+
+
@@ -312,7 +327,7 @@ L/tmp/foobar ----
/dev/null
objects. For z, Z lines, if omitted or when set
to -, the file access mode will not be
modified. This parameter is ignored for x, r,
-R, L lines.
+R, L, t lines.
@@ -324,7 +339,7 @@ L/tmp/foobar ----
/dev/null
omitted or when set to -, the default 0 (root)
is used. For z, Z lines, when omitted or when set to -,
the file ownership will not be modified.
-These parameters are ignored for x, r, R, L
lines.
+These parameters are ignored for x, r, R, L, t
lines.
@@ -377,8 +392,10 @@ L/tmp/foobar ----
/dev/null
minor formatted as integers, separated by :,
e.g. "1:3". For f, F, w may be used to specify
a short string that is written to the file,
-suffixed by a newline. Ignored for all other
+suffixed by a newline. For t determines extended
+attributes to be set. Ignored for all other
lines.
+
@@ -390,7 +407,8 @@ L/tmp/foobar ----
/dev/null
screen needs two directories
created at boot with specific modes and ownership.
d /var/run/screens 1777 root root 10d
-d /var/run/uscreens 0755 root root 10d12h
+d /var/run/uscreens 0755 root root 10d12h
+t /var/run/screen - - - - user.name="John Koval"
security.SMACK64=screen
/etc/tmpfiles.d/abrt.conf example
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index b7f6a2e..ec5efb6 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -39,6 +39,9 @@
#include
#include
#include
+#ifdef HAVE_XATTR
+#include
+#endif
#include "log.h"
#include "util.h"
@@ -78,7 +81,10 @@ typedef enum ItemType {
REMOVE_PATH = 'r',
RECURSIVE_REMOVE_PATH = 'R',
RELABEL_PATH = 'z',
-RECURSIVE_RELABEL_PATH = 'Z'
+RECURSIVE_RELABEL_PATH = 'Z',
+
+/* Th
[systemd-devel] [PATCH] libsystemd-bus: Add return error msg for unicast signals when well-known name is not available
ENXIO, ESRCH and EADDRNOTAVAIL are also returned by ioctl(KDBUS_CMD_MSG_SEND)
when we have unicast signal messages (signals with a DESTINATION field).
---
src/libsystemd-bus/bus-kernel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c
index b85a10d..1499830 100644
--- a/src/libsystemd-bus/bus-kernel.c
+++ b/src/libsystemd-bus/bus-kernel.c
@@ -414,7 +414,7 @@ int bus_kernel_write_message(sd_bus *bus, sd_bus_message
*m) {
/* ENXIO: unique name not known
* ESRCH: well-known name not known */
-if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL)
+if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL ||
m->header->type == SD_BUS_MESSAGE_SIGNAL)
sd_bus_error_setf(&error,
SD_BUS_ERROR_SERVICE_UNKNOWN, "Destination %s not known", m->destination);
else
return 0;
@@ -423,7 +423,7 @@ int bus_kernel_write_message(sd_bus *bus, sd_bus_message
*m) {
/* EADDRNOTAVAIL: activation is possible, but turned
off in request flags */
-if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL)
+if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL ||
m->header->type == SD_BUS_MESSAGE_SIGNAL)
sd_bus_error_setf(&error,
SD_BUS_ERROR_SERVICE_UNKNOWN, "Activation of %s not requested", m->destination);
else
return 0;
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journald API, sd_journal_seek_tail()
Hi, I'm working on Fedora 19 with systemd 204. I had trouble with the journald-API regarding the seek_tail function. The bug is already described here: https://bugs.freedesktop.org/show_bug.cgi?id=64614 Here is one more related post: https://bugzilla.redhat.com/show_bug.cgi?id=979487 I guess this is no problem of Fedora. There seems to be a workaround in the second link. Whats the status of this bug? - Sascha Kattelmann ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/7] libsystemd-bus: bring definitions in sync with kdbus
On 12/04/2013 09:13 AM, Yin Kangkai wrote: > On 2013-12-04, 08:49 +0100, Daniel Mack wrote: >>> Actually, I have a stupid question, do we have any particular reason >>> to use "part/PART"? giving the fact that we already have term "item" >>> everywhere in the code... >>> >>> struct kdbus_item, items, kdbus_msg.items... >>> >>> My opinion, on the contrary, we should replace all the KDBUS_PART_xxx >>> into KDBUS_ITEM_xxx, that seems more reasonable to me :) >> >> Nope. A 'part' is more generic: anything that has size header and a >> dynamic length is a 'part' and can be iterated over with >> KDBUS_PART_FOREACH. Hence, an 'item' is a 'part', but not vice versa. >> See struct kdbus_name_list for example. > > Thanks Daniel for the reply. > > OK now I understand KDBUS_PART_NEXT/FOREACH is not only for > "item". > > But KDBUS_PART_HEADER_SIZE and KDBUS_PART_SIZE seems "item" specific, > no? You're right, it's used in that context only, and it assumes 2 * sizeof(u64) as header size, so we should probably rename it. We've changed thing forth and back a couple of times. Give us some time to reconsider :) Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/7] libsystemd-bus: bring definitions in sync with kdbus
On 2013-12-04, 08:49 +0100, Daniel Mack wrote: > > Actually, I have a stupid question, do we have any particular reason > > to use "part/PART"? giving the fact that we already have term "item" > > everywhere in the code... > > > > struct kdbus_item, items, kdbus_msg.items... > > > > My opinion, on the contrary, we should replace all the KDBUS_PART_xxx > > into KDBUS_ITEM_xxx, that seems more reasonable to me :) > > Nope. A 'part' is more generic: anything that has size header and a > dynamic length is a 'part' and can be iterated over with > KDBUS_PART_FOREACH. Hence, an 'item' is a 'part', but not vice versa. > See struct kdbus_name_list for example. Thanks Daniel for the reply. OK now I understand KDBUS_PART_NEXT/FOREACH is not only for "item". But KDBUS_PART_HEADER_SIZE and KDBUS_PART_SIZE seems "item" specific, no? Regards, Kangkai ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
