Re: [systemd-devel] [PATCH 1/3] metadata: document creds_item_off and auxgrps_item_off fields
On 08/19/2014 03:43 AM, Djalal Harouni wrote: Signed-off-by: Djalal Harouni tix...@opendz.org --- metadata.c | 3 ++- metadata.h | 8 +++- 2 files changed, 9 insertions(+), 2 deletions(-) Applied, thanks! diff --git a/metadata.c b/metadata.c index eb286aa..3dff9ac 100644 --- a/metadata.c +++ b/metadata.c @@ -130,7 +130,8 @@ kdbus_meta_append_item(struct kdbus_meta *meta, u64 type, size_t payload_size) * kdbus_meta_append_data() - append given raw data to metadata object * @meta:Metadata object * @type:KDBUS_ITEM_* type - * @data:pointer to data to copy from + * @data:pointer to data to copy from. If it is NULL + * then just make space in the metadata buffer. * @len: number of bytes to copy * * Return: 0 on success, negative errno on failure. diff --git a/metadata.h b/metadata.h index a142aea..1bdb537 100644 --- a/metadata.h +++ b/metadata.h @@ -16,10 +16,16 @@ /** * struct kdbus_meta - metadata buffer * @attached:Flags for already attached data - * @domain: Domain the metadata belongs to + * @domain: Domain the metadata belongs to * @data:Allocated buffer * @size:Number of bytes used * @allocated_size: Size of buffer + * @creds_item_off The offset of the creds item in the @data + * buffer field, if the user requested this + * metainfo in its attach flags. 0 if unused. + * @auxgrps_item_off The offset of the auxgroups item in the + * @data buffer field, if the user requested + * this metainfo. 0 if unused. * * Used to collect and store connection metadata in a pre-compiled * buffer containing struct kdbus_item. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] kdbus: get some creds during meta append for optimization
Hi Djalal,
On 08/19/2014 03:43 AM, Djalal Harouni wrote:
Some creds can be gathered during kdbus_meta_append() instead of
kdbus_conn_queue_alloc() where they will be gathered for all the
receivers and saved into each receivers queue before installing
on the slices.
By moving to kdbus_meta_append() it permits to do it only one time
for all the receivers, and we reduce some latency in
kdbus_conn_queue_alloc().
Another point is that all the receivers will get the same uid/gid even
if the current sender changes its creds while we are still queueing for
all receivers.
It seems that we can do the same with auxgroups, but this patch does
not implement it.
Patch tested with the test-kdbus-metadata-ns
Signed-off-by: Djalal Harouni tix...@opendz.org
---
connection.c | 56
metadata.c | 6 +-
metadata.h | 26 ++
3 files changed, 67 insertions(+), 21 deletions(-)
diff --git a/connection.c b/connection.c
index 9250dab..49c5045 100644
--- a/connection.c
+++ b/connection.c
@@ -42,6 +42,24 @@
struct kdbus_conn_reply;
/**
+ * struct kdbus_queue_creds - internal creds data for receiver's
+ * queue
+ * @uid: The UID to patch into the final message
+ * @gid: The GID to patch into the final message
+ * @pid: The PID to patch into the final message
+ * @tid: The TID to patch into the final message
+ *
+ * Creds that must be translated into the receiver's namespaces
+ * when the message is installed into its slice.
+ */
+struct kdbus_queue_creds {
+ kuid_t uid;
+ kgid_t gid;
+ struct pid *pid;
+ struct pid *tid;
+};
Hmm, I'm not convinced this buys us anything really. After all, that
struct has a single user only, and factoring out these fields doesn't
necessarily lead to more readability.
[...]
/**
+ * struct kdbus_meta_creds - internal creds data
+ * @uid:The UID of the sender
+ * @gid:The GID of the sender
+ *
+ * Creds used for optimizations. We need to gather the info during
+ * kdbus_meta_append() before pushing into the receiver's queue,
+ * this way we do it only one time for all the receivers.
I'm not strictly against it, but I wonder if this optimization is really
worth it. Do you think it's that expensive to access these fields in
'current'? Because this change certainly doesn't make the code easier to
understand, so I'm hesitant about this change.
Thanks,
Daniel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] start / stop daemon
Hi, I do not know whether this is something systemd should handle or if it is something that belongs to the kernel, so let me ask this first: Is starting and stopping a daemon part of something systemd is / becomes responsible for? If so I have something I want to say about that for future developments, if not I need to post that topic somewhere else. Bonno Bloksma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start / stop daemon
On Tue, Aug 19, 2014 at 12:12 PM, Bonno Bloksma b.blok...@tio.nl wrote: Hi, I do not know whether this is something systemd should handle or if it is something that belongs to the kernel, so let me ask this first: Is starting and stopping a daemon part of something systemd is / becomes responsible for? Well, yes, starting stopping daemons is pretty much the *primary function* of systemd; it's part of the job of being an init system. (Although the old SysVinit would rather delegate this to shellscripts.) The kernel still manages individual processes (fork/exec/exit), of course; but it's not the kernel's job to care about what is a 'daemon' nor what daemons should be started when. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journalctl: add -t --identifier=STRING option
From: Harald Hoyer har...@redhat.com
This turns journalctl to the counterpart of systemd-cat.
Messages sent with
systemd-cat --identifier foo --prioritiy debug
can now be shown with
journalctl --identifier foo --prioritiy debug
--identifier is not merged with --unit to make a clear
distinction between syslog and systemd units.
syslog identifiers can be chosen freely by anyone.
---
man/journalctl.xml | 14 ++
src/journal/journalctl.c | 43 ++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/man/journalctl.xml b/man/journalctl.xml
index bf18756..906ffd0 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -498,6 +498,20 @@
/varlistentry
varlistentry
+termoption-t/option/term
+
termoption--identifier=replaceableSYSLOG_IDENTIFIER/replaceable|replaceablePATTERN/replaceable/option/term
+
+listitemparaShow messages for the
+specified syslog identifier
+replaceableSYSLOG_IDENTIFIER/replaceable,
or
+for any of the messages with a
literalSYSLOG_IDENTIFIER/literal
+matched by
replaceablePATTERN/replaceable./para
+
+paraThis parameter can be specified
+multiple times./para/listitem
+/varlistentry
+
+varlistentry
termoption-u/option/term
termoption--unit=replaceableUNIT/replaceable|replaceablePATTERN/replaceable/option/term
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 5c4a71d..3037fb8 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -89,6 +89,7 @@ static bool arg_force = false;
#endif
static usec_t arg_since, arg_until;
static bool arg_since_set = false, arg_until_set = false;
+static char **arg_syslog_identifier = NULL;
static char **arg_system_units = NULL;
static char **arg_user_units = NULL;
static const char *arg_field = NULL;
@@ -180,6 +181,7 @@ static void help(void) {
-k --dmesg Show kernel message log from the
current boot\n
-u --unit=UNIT Show data only from the specified
unit\n
--user-unit=UNIT Show data only from the specified
user session unit\n
+ -t --identifier=STRING Show only messages wit the
specified syslog identifier\n
-p --priority=RANGE Show only messages within the
specified priority range\n
-e --pager-end Immediately jump to end of the
journal in the pager\n
-f --follow Follow the journal\n
@@ -276,6 +278,7 @@ static int parse_argv(int argc, char *argv[]) {
{ file, required_argument, NULL, ARG_FILE
},
{ root, required_argument, NULL, ARG_ROOT
},
{ header, no_argument, NULL, ARG_HEADER
},
+{ identifier, required_argument, NULL, 't'
},
{ priority, required_argument, NULL, 'p'
},
{ setup-keys, no_argument, NULL, ARG_SETUP_KEYS
},
{ interval, required_argument, NULL, ARG_INTERVAL
},
@@ -304,7 +307,7 @@ static int parse_argv(int argc, char *argv[]) {
assert(argc = 0);
assert(argv);
-while ((c = getopt_long(argc, argv, hefo:aln::qmb::kD:p:c:u:F:xrM:,
options, NULL)) = 0)
+while ((c = getopt_long(argc, argv,
hefo:aln::qmb::kD:p:c:t:u:F:xrM:, options, NULL)) = 0)
switch (c) {
@@ -590,6 +593,12 @@ static int parse_argv(int argc, char *argv[]) {
arg_until_set = true;
break;
+case 't':
+r = strv_extend(arg_syslog_identifier, optarg);
+if (r 0)
+return log_oom();
+break;
+
case 'u':
r = strv_extend(arg_system_units, optarg);
if (r 0)
@@ -1212,6 +1221,32 @@ static int add_priorities(sd_journal *j) {
return 0;
}
+
+static int add_syslog_identifier(sd_journal *j) {
+int r;
+char **i;
+
+assert(j);
+
+STRV_FOREACH(i, arg_syslog_identifier) {
+char *u;
+
+u = strappenda(SYSLOG_IDENTIFIER=, *i);
+r = sd_journal_add_match(j, u, 0);
+if (r 0)
+return r;
+r = sd_journal_add_disjunction(j);
+if (r 0)
+return
[systemd-devel] Machines, VMs, Container listing
Hello all, What is the difference between: systemctl list-machines versus machinectl list It seems that systemctl list-machines shows my current machine. But nothing on machinectl. Are they going to merged together any time soon? Thanks, Roger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logind error - Failed to abandon session scope: Connection reset
Roger Qiu wrote on 19/08/14 01:42: Hello Lennart, I'm not familiar with the SystemD codebase FYI, it's systemd not SystemD or systemD. Hardly a big deal, but figured I'd correct while nitpicking other bits. https://github.com/systemd/systemd so I don't where I could patch the error message. Note that the primary repository is not on GitHub. GitHub is just a mirror that syncs automatically after successful CI builds. The primary repo is: http://cgit.freedesktop.org/systemd/systemd/ On the other hand, is the kdbus production ready even though it hasn't been merged into the kernel? I'm curious what would be the procedure to install kdbus (https://github.com/gregkh/kdbus) and replace my current userspace systemd? This too is not the primary code repo. It's currently kept primarily on https://code.google.com/p/d-bus/ and synced to Greg's repo regularly. There doesn't seem to be any guides/documentation on that area. I'll let Lennart reply, with more details, but I suspect it's not quite ready for production use yet and API stability is not fully guaranteed until it's merged! I'm sure they'd welcome some more testers putting it through it's paces tho', but be prepared for adapting your side as it progresses! :) That said, unless you are really interested in this solution for other reasons, it seems like rather large hammer to crack this particular walnut! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Logind error - Failed to abandon session scope: Connection reset
On Tue, 19.08.14 10:42, Roger Qiu (roger@polycademy.com) wrote: Heya, I'm not familiar with the SystemD codebase https://github.com/systemd/systemd so I don't where I could patch the error message. On the other hand, is the kdbus production ready even though it hasn't been merged into the kernel? No it is not. We are currently rebasing it on the new memfd kernel primitive that we managed to get into the 3.17 kernel. The code is pretty comprehensive now, but the interfaces and the code are still subject to change before we push it upstream. The userspace side of it lives in systemd, but you have to acknowledge that you are aware that it isn't stable yet by passing --enable-kdbus to configure. I'm curious what would be the procedure to install kdbus (https://github.com/gregkh/kdbus) and replace my current userspace systemd? There doesn't seem to be any guides/documentation on that area. You shouldn only do that if you are a developer and know what you do. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Machines, VMs, Container listing
On Tue, 19.08.14 21:02, Roger Qiu (roger@polycademy.com) wrote: Hello all, What is the difference between: systemctl list-machines This lists the locally running containers, and the state of systemd in them. It basically tells you about which contaienrs are healthy and which ones aren't. machinectl list This lists all locally running containers and VMs, it shows nothing about what's running inside of them. It seems that systemctl list-machines shows my current machine. But nothing on machinectl. Are they going to merged together any time soon? I don't think so. systemctl is a tool for exploring the system manager's state, on the host and in containers. machinectl is much more superficial, it just lists you whatever is registered, and doesn't go into the contaienrs. It also knows about VMs, where systemctl list-machines doesn't. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] kdbus: merge 3.17 branch into master?
Hi all, Now that memfd is merged into 3.17-rc1, should we merge the 3.17 branch in the kdbus tree into master as well? Right now, the test directory on master doesn't build properly on older kernels due to linux/memfd.h not being present, so it seems that we are already thinking the code is there: TARGET_CC kdbus-util.o kdbus-util.c:27:25: fatal error: linux/memfd.h: No such file or directory #include linux/memfd.h ^ thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Shutdown notify
Hi all, I would like to know if there is a possibility to get notified about upcoming shutdown/restart. For example: . Somebody executes systemctl reboot / systemctl poweroff . A callback function is called in my service before SIGTERM is triggered on ANY service. . After my callback returns, the systemd continues the reboot/shutdown process. I suppose it's possible via dbus API, but I couldn't find any examples connected with this scenario. Thanks in advance. Best regards, Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
Hi Greg On Tue, Aug 19, 2014 at 1:29 PM, Greg KH gre...@linuxfoundation.org wrote: Hi all, Now that memfd is merged into 3.17-rc1, should we merge the 3.17 branch in the kdbus tree into master as well? Right now, the test directory on master doesn't build properly on older kernels due to linux/memfd.h not being present, so it seems that we are already thinking the code is there: TARGET_CC kdbus-util.o kdbus-util.c:27:25: fatal error: linux/memfd.h: No such file or directory #include linux/memfd.h ^ I thought Daniel already cherry-picked the patches from the 3.17 branch into master? david@david-tp ~/dev/kdbus $ git log master..origin/3.17 --oneline b59133f metadata: drop support for kernels v3.15 307be39 Kconfig: depend on TMPFS 60a5b53 test: adopt new memfd interface 790a8a8 switch to upstream kernel memfd implementation (ABI+API break) 7219f86 metadata: follow 3.17 changes for current-start_time All these patches are available in master (with different sha1 due to cherry-pick). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown notify
On Tue, 19.08.14 13:34, Michal Witanowski (m.witanow...@samsung.com) wrote: Hi all, I would like to know if there is a possibility to get notified about upcoming shutdown/restart. For example: . Somebody executes systemctl reboot / systemctl poweroff . A callback function is called in my service before SIGTERM is triggered on ANY service. . After my callback returns, the systemd continues the reboot/shutdown process. I suppose it's possible via dbus API, but I couldn't find any examples connected with this scenario. Thanks in advance. You can use logind's shutdown delay inhibit locks: http://www.freedesktop.org/wiki/Software/systemd/inhibit/ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On 08/19/2014 01:39 PM, David Herrmann wrote: Hi Greg On Tue, Aug 19, 2014 at 1:29 PM, Greg KH gre...@linuxfoundation.org wrote: Hi all, Now that memfd is merged into 3.17-rc1, should we merge the 3.17 branch in the kdbus tree into master as well? Right now, the test directory on master doesn't build properly on older kernels due to linux/memfd.h not being present, so it seems that we are already thinking the code is there: TARGET_CC kdbus-util.o kdbus-util.c:27:25: fatal error: linux/memfd.h: No such file or directory #include linux/memfd.h ^ I thought Daniel already cherry-picked the patches from the 3.17 branch into master? david@david-tp ~/dev/kdbus $ git log master..origin/3.17 --oneline b59133f metadata: drop support for kernels v3.15 307be39 Kconfig: depend on TMPFS 60a5b53 test: adopt new memfd interface 790a8a8 switch to upstream kernel memfd implementation (ABI+API break) 7219f86 metadata: follow 3.17 changes for current-start_time Yes, I already merged the patches I've been holding back until 3.17-rc1 was released. However, there was one missing detail to fix the build in test/ which I pushed now. Does it work for you? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On Tue, Aug 19, 2014 at 01:45:29PM +0200, Daniel Mack wrote: Yes, I already merged the patches I've been holding back until 3.17-rc1 was released. Ah, sorry, missed that. However, there was one missing detail to fix the build in test/ which I pushed now. Does it work for you? Nope, build is still broken: me/gregkh/linux/kdbus/test' TARGET_CC kdbus-enum.o In file included from ../kdbus.h:23:0, from kdbus-util.h:13, from kdbus-enum.c:20: /lib/modules/3.16.0+/build/include/uapi/linux/types.h:9:2: warning: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; [-Wcpp] #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; ^ In file included from /lib/modules/3.16.0+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.16.0+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, from kdbus-util.h:13, from kdbus-enum.c:20: /lib/modules/3.16.0+/build/include/uapi/linux/stddef.h:1:28: fatal error: linux/compiler.h: No such file or directory #include linux/compiler.h ^ compilation terminated. Oh wait, I'm pointing it at a 3.16.0 release at the moment, let's change that... Nope, still broken, as you are relying on memfd.h to be included on the system: $ KERNELDIR=../gregkh/ make make -C ../gregkh/ M=/home/gregkh/linux/kdbus make[1]: Entering directory '/home/gregkh/linux/gregkh' Building modules, stage 2. MODPOST 1 modules make[1]: Leaving directory '/home/gregkh/linux/gregkh' make -C test KERNELDIR=../gregkh/ KBUILD_MODNAME=kdbus make[1]: Entering directory '/home/gregkh/linux/kdbus/test' TARGET_CC kdbus-enum.o TARGET_CC kdbus-util.o kdbus-util.c:27:25: fatal error: linux/memfd.h: No such file or directory #include linux/memfd.h ^ compilation terminated. I'll reboot into 3.17-rc1 and see if that solves this... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On Tue, Aug 19, 2014 at 07:37:12AM -0500, Greg KH wrote: I'll reboot into 3.17-rc1 and see if that solves this... Nope, same error as before: make[1]: Entering directory '/home/gregkh/linux/kdbus/test' TARGET_CC kdbus-enum.o In file included from ../kdbus.h:23:0, from kdbus-util.h:13, from kdbus-enum.c:20: /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:9:2: warning: #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; [-Wcpp] #warning Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders; ^ In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, from kdbus-util.h:13, from kdbus-enum.c:20: /lib/modules/3.17.0-rc1+/build/include/uapi/linux/stddef.h:1:28: fatal error: linux/compiler.h: No such file or directory #include linux/compiler.h ^ compilation terminated. How are you building this file? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown notify
What if I'm using systemd built without logind? -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Tuesday, August 19, 2014 1:40 PM To: Michal Witanowski Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Shutdown notify On Tue, 19.08.14 13:34, Michal Witanowski (m.witanow...@samsung.com) wrote: Hi all, I would like to know if there is a possibility to get notified about upcoming shutdown/restart. For example: . Somebody executes systemctl reboot / systemctl poweroff . A callback function is called in my service before SIGTERM is triggered on ANY service. . After my callback returns, the systemd continues the reboot/shutdown process. I suppose it's possible via dbus API, but I couldn't find any examples connected with this scenario. Thanks in advance. You can use logind's shutdown delay inhibit locks: http://www.freedesktop.org/wiki/Software/systemd/inhibit/ Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On 08/19/2014 02:37 PM, Greg KH wrote: $ KERNELDIR=../gregkh/ make make -C ../gregkh/ M=/home/gregkh/linux/kdbus make[1]: Entering directory '/home/gregkh/linux/gregkh' Building modules, stage 2. MODPOST 1 modules make[1]: Leaving directory '/home/gregkh/linux/gregkh' make -C test KERNELDIR=../gregkh/ KBUILD_MODNAME=kdbus Hmm, yes. KERNELDIR has to be an absolute path. I pushed a fix to address this and convert a possible relative path into an absolute one. Does this help? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown notify
On Tue, 19.08.14 14:49, Michal Witanowski (m.witanow...@samsung.com) wrote: What if I'm using systemd built without logind? Not available then. Sorry. You only have the time between SIGTERM and your processes' exit(). It's pretty much logind's job to implement things like these inhibitors. If don't enable it you don't get the functionality accordingly. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] compile with clang broken
On Sat, Aug 16, 2014 at 5:35 AM, David Herrmann dh.herrm...@gmail.com
wrote:
Hi
On Fri, Aug 15, 2014 at 5:22 PM, Daniele Nicolodi dani...@grinta.net
wrote:
On 15/08/2014 16:30, David Herrmann wrote:
Ok, took me a while, but I now figured out how to cause compilation to
fail even in expressions that initialize types (_Static_assert is not
allowed there):
#define assert_const(expr)
((void)(__builtin_types_compatible_p(int[(expr) ? 1 : -1], int[1])))
Btw., I like that more than our current assert_cc() fallback. But I
leave it up to you to decide.
Anyhow, I found a way to make CONST_MAX work:
#define CONST_MAX(_A, _B)
(__builtin_choose_expr(__builtin_constant_p(_A)
__builtin_constant_p(_B), ((_A) (_B)) ? (_A) : (_B), (void)0))
This will return (void) in case _A or _B is not constant. Works fine
on LLVM, I now have to test it on gcc. If it works, I will commit it
and fix resolvd.
Hello,
this may be completely stupid, but if the only use case you have for
CONST_MAX() is for computing the size of a data structure, I find
something like
#define MAXSIZE(A, B) sizeof(union { __typeof(A) a; __typeof(B) b;})
a little more clear and less magic, and I believe it has the same
guarantees that the solution you found.
Your MAXSIZE macro might add padding:
union A {
int a;
char b[5];
};
This union has size 8, not 5 (64bit). But CONST_MAX would return 5.
Not sure whether that really matters, though. And we could probably
add __packed__ to the definition.
However, I noticed that GCC complains about using
statement-expressions to initialize static-const structure members,
even with my 'const' annotations added to MAX. *sigh*
Thus, I think I'll keep CONST_MAX, as we'd require a 3rd macro otherwise.
If you know a way to unify them all, please lemme know.
Thanks for getting this in! I had given up on receiving constructive
feedback on my attempt to solve this earlier [1]. Glad your patch garnered
useful feedback that got to a committable result!
-Dan
[1]
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021761.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On 08/19/2014 02:47 PM, Greg KH wrote: In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, Ok, got it now. No idea why it worked on my system, but a fix for now is to make cpp look at the system include file search pathes first, and then fall back to $(KERNELDIR)/include/uapi. Care to test again? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On Tue, Aug 19, 2014 at 03:24:39PM +0200, Daniel Mack wrote: On 08/19/2014 02:47 PM, Greg KH wrote: In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, Ok, got it now. No idea why it worked on my system, but a fix for now is to make cpp look at the system include file search pathes first, and then fall back to $(KERNELDIR)/include/uapi. Care to test again? Close, I now get a bunch of these warnings: cc1: note: obsolete option -I- used, please use -iquote instead and then finally a failure of: kdbus-util.c:173:16: error: ‘__NR_memfd_create’ undeclared (first use in this function) ret = syscall(__NR_memfd_create, name, MFD_ALLOW_SEALING); ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On 08/19/2014 03:56 PM, Greg KH wrote: On Tue, Aug 19, 2014 at 03:24:39PM +0200, Daniel Mack wrote: On 08/19/2014 02:47 PM, Greg KH wrote: In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, Ok, got it now. No idea why it worked on my system, but a fix for now is to make cpp look at the system include file search pathes first, and then fall back to $(KERNELDIR)/include/uapi. Care to test again? Close, I now get a bunch of these warnings: cc1: note: obsolete option -I- used, please use -iquote instead and then finally a failure of: kdbus-util.c:173:16: error: ‘__NR_memfd_create’ undeclared (first use in this function) ret = syscall(__NR_memfd_create, name, MFD_ALLOW_SEALING); Ok, cpp is really confused about which headers to look at now. I guess we have to rely on the kernel headers being available under $(KERNELDIR)/usr/include. Could you please try if temporarily reverting my top-most commit and then doing a 'make headers_install' in your kernel repo (before you build kdbus) fixes it? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On Tue, Aug 19, 2014 at 08:56:14AM -0500, Greg KH wrote: On Tue, Aug 19, 2014 at 03:24:39PM +0200, Daniel Mack wrote: On 08/19/2014 02:47 PM, Greg KH wrote: In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, Ok, got it now. No idea why it worked on my system, but a fix for now is to make cpp look at the system include file search pathes first, and then fall back to $(KERNELDIR)/include/uapi. Care to test again? Close, I now get a bunch of these warnings: cc1: note: obsolete option -I- used, please use -iquote instead and then finally a failure of: kdbus-util.c:173:16: error: ‘__NR_memfd_create’ undeclared (first use in this function) ret = syscall(__NR_memfd_create, name, MFD_ALLOW_SEALING); I also confirm, HEAD gives these errors! However yesterday before any change to Makefile, I got the same error that was first reported by Greg, and to compile and test kdbus, I just added export KERNELDIR to the root Makefile, didn't bother to search... -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On Tue, Aug 19, 2014 at 04:08:15PM +0200, Daniel Mack wrote: On 08/19/2014 03:56 PM, Greg KH wrote: On Tue, Aug 19, 2014 at 03:24:39PM +0200, Daniel Mack wrote: On 08/19/2014 02:47 PM, Greg KH wrote: In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, Ok, got it now. No idea why it worked on my system, but a fix for now is to make cpp look at the system include file search pathes first, and then fall back to $(KERNELDIR)/include/uapi. Care to test again? Close, I now get a bunch of these warnings: cc1: note: obsolete option -I- used, please use -iquote instead and then finally a failure of: kdbus-util.c:173:16: error: ‘__NR_memfd_create’ undeclared (first use in this function) ret = syscall(__NR_memfd_create, name, MFD_ALLOW_SEALING); Ok, cpp is really confused about which headers to look at now. I guess we have to rely on the kernel headers being available under $(KERNELDIR)/usr/include. Could you please try if temporarily reverting my top-most commit and then doing a 'make headers_install' in your kernel repo (before you build kdbus) fixes it? Daniel, I confirm here. I just did that and it builds. Thanks -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On Tue, Aug 19, 2014 at 04:08:15PM +0200, Daniel Mack wrote: On 08/19/2014 03:56 PM, Greg KH wrote: On Tue, Aug 19, 2014 at 03:24:39PM +0200, Daniel Mack wrote: On 08/19/2014 02:47 PM, Greg KH wrote: In file included from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/posix_types.h:4:0, from /lib/modules/3.17.0-rc1+/build/include/uapi/linux/types.h:13, from ../kdbus.h:23, Ok, got it now. No idea why it worked on my system, but a fix for now is to make cpp look at the system include file search pathes first, and then fall back to $(KERNELDIR)/include/uapi. Care to test again? Close, I now get a bunch of these warnings: cc1: note: obsolete option -I- used, please use -iquote instead and then finally a failure of: kdbus-util.c:173:16: error: ‘__NR_memfd_create’ undeclared (first use in this function) ret = syscall(__NR_memfd_create, name, MFD_ALLOW_SEALING); Ok, cpp is really confused about which headers to look at now. I guess we have to rely on the kernel headers being available under $(KERNELDIR)/usr/include. Could you please try if temporarily reverting my top-most commit and then doing a 'make headers_install' in your kernel repo (before you build kdbus) fixes it? Yes, that works. And we can live with that, it's reasonable to rely on that kernel header now. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus: merge 3.17 branch into master?
On 08/19/2014 04:21 PM, Greg KH wrote: On Tue, Aug 19, 2014 at 04:08:15PM +0200, Daniel Mack wrote: Could you please try if temporarily reverting my top-most commit and then doing a 'make headers_install' in your kernel repo (before you build kdbus) fixes it? Yes, that works. And we can live with that, it's reasonable to rely on that kernel header now. Alright. Revert commit is pushed now. Thanks for testing! Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start / stop daemon
Hi, I do not know whether this is something systemd should handle or if it is something that belongs to the kernel, so let me ask this first: Is starting and stopping a daemon part of something systemd is / becomes responsible for? Well, yes, starting stopping daemons is pretty much the *primary function* of systemd; it's part of the job of being an init system. (Although the old SysVinit would rather delegate this to shellscripts.) The kernel still manages individual processes (fork/exec/exit), of course; but it's not the kernel's job to care about what is a 'daemon' nor what daemons should be started when. In that case I would like to ask if the developers have already considered a development in the Windows world considering the stopping of services that may take a LOOONG time stopping, for instance some databases. I wonder if the people developing systemd are paying attention to a development in de Windows environment where the latest thing is that de service can report back that it is indeed still trying to stop and not just hung or not reporting back. Windows will now kill a service after a certain time when shutting down, in some cases it is killing a database that took A LONG TIME to shut down and cause the database to become inconsistent. The new development is to make sure that does not happen. If systemd is trying to become smart about stopping services it might be a good idea to have this built in. Also not just have the service report back I am still busy but also with a progress indicator which NEEDS to increase at each report so systemd can detect whether the service is indeed progressing towards a stopped state or hung in the getting there. From the past I have seen things go wrong in communication when the only thing reported back is I am busy while there was no progress being made toward the finish. Is this something the systemd team has already put on the todo list or am I the first to suggest it? Bonno Bloksma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start / stop daemon
Bonno Bloksma wrote on 19/08/14 15:44: In that case I would like to ask if the developers have already considered a development in the Windows world considering the stopping of services that may take a LOOONG time stopping, for instance some databases. I wonder if the people developing systemd are paying attention to a development in de Windows environment where the latest thing is that de service can report back that it is indeed still trying to stop and not just hung or not reporting back. Windows will now kill a service after a certain time when shutting down, in some cases it is killing a database that took A LONG TIME to shut down and cause the database to become inconsistent. The new development is to make sure that does not happen. If systemd is trying to become smart about stopping services it might be a good idea to have this built in. Also not just have the service report back I am still busy but also with a progress indicator which NEEDS to increase at each report so systemd can detect whether the service is indeed progressing towards a stopped state or hung in the getting there. From the past I have seen things go wrong in communication when the only thing reported back is I am busy while there was no progress being made toward the finish. Is this something the systemd team has already put on the todo list or am I the first to suggest it? There is certainly prior art with regards to the Type=notify units. These units use a small notification protocol to implement a type of watchdog support and signal systemd when it's ready (i.e. passed the early initialisation phase and available for anything that relies on it). The application can then use the protocol to report back a status line that appears in the systemctl status output. I'm not sure of the top of my head if there is anything in this protocol that allows modification of any timeouts, but systemd already has support for showing the user feedback about slow running stop jobs although I believe this is limited to the startup/shutdown sequences rather than interactively via systemctl... could be wrong tho'. Anyway, the long and short of it is, that there is a lot already in systemd related to this, so in theory it shouldn't be too hard to integrate support, but I don't think there is something that does this exactly at present. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] man/systemd.socket.xml src/core src/shared
On Tue, 19.08.14 09:57, Michal Sekletar (msekl...@kemper.freedesktop.org) wrote:
Hi!
Hmm, can we please have patches like this sent to the ML?
I am not sure I like the SELinuxLabelViaNet= name. Can we name this
SELinuxContextFromNet= at least?
We currently have SELinuxContext=, and afaik label and conetxt are
kinda the same thing, could we please stick to one nomenclature here?
varlistentry
+ termvarnameSELinuxLabelViaNet=/varname/term
+ listitemparaTakes a boolean
+ value. Controls whether systemd attempts to figure
out
+ SELinux label used for instantiated service from
+ information handed by peer over the
+ network. Configuration option has effect only
+ on sockets with literalAccept=/literal
+ mode set to
literalyes/literal./para/listitem
+/varlistentry
+
+varlistentry
This is indented differently from the rest of the file.
+
+if (context-selinux_label_via_net use_selinux())
{
+_cleanup_free_ char *label = NULL;
+
+err = label_get_child_label(socket_fd,
command-path, label);
+if (err 0) {
+r = EXIT_SELINUX_CONTEXT;
+goto fail_child;
+}
+
+err = setexeccon(label);
+if (err 0) {
+r = EXIT_SELINUX_CONTEXT;
+goto fail_child;
+}
+}
You forgot to check if socket_fd is actually valid here.
There's also the question what actually happens if both SELinuxContext=
and this new thing are set. We probably should clearly prefer one over
the other and only apply that in such a case, instead of applying first
one, and then the other.
Did you actually see my earlier review?
http://lists.freedesktop.org/archives/systemd-devel/2014-August/021922.html
I already raised all the issues I am pointing out now, then.
I'll revert this for now, please send an updated patch to the ML, and we
can review and merge it.
Thanks!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd fails to activate the device on boot
Am 18.08.2014 um 12:41 schrieb Tom Gundersen: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). [2.211121] lije systemd[1]: Starting Network Service... [2.230579] lije systemd-networkd[356]: timestamp of '/etc/systemd/network' changed [2.231454] lije systemd-networkd[356]: qemu: Creating tuntap netdev: tap [2.232121] lije systemd-networkd[356]: qemu: loaded tap [2.234423] lije systemd-networkd[356]: qemu: link 3 added [2.234527] lije systemd-networkd[356]: qemu: udev initialized link [2.234630] lije systemd-networkd[356]: qemu: netdev has index 3 [2.234720] lije systemd-networkd[356]: qemu: flags change: +MULTICAST +BROADCAST [2.236465] lije systemd-networkd[356]: qemu: udev initialized link [2.236562] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [2.236703] lije systemd-networkd[356]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a [2.236852] lije systemd-networkd[356]: qemu: link state is up-to-date [2.237117] lije systemd-networkd[356]: qemu: found matching network '/etc/systemd/network/01-qemu.network' [2.237673] lije systemd-networkd[356]: qemu: enslaved [2.23] lije systemd-networkd[356]: qemu: bringing link up [2.237876] lije systemd-networkd[356]: qemu: setting addresses [2.237972] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [2.238057] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [2.238155] lije systemd[1]: Started Network Service. [2.238263] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [2.238608] lije systemd-networkd[356]: qemu: flags change: +UP +RUNNING [2.238702] lije systemd-networkd[356]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.2 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a [2.238810] lije systemd-networkd[356]: Got message type=signal sender=org.freedesktop.DBus destination=:1.2 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a [2.238906] lije systemd-networkd[356]: qemu: added address: 10.23.42.129/26 [2.238993] lije systemd-networkd[356]: qemu: addresses set [2.239328] lije systemd-networkd[356]: qemu: link configured [2.239430] lije systemd-networkd[356]: qemu: MAC address: 1a:de:ad:be:ef:01 [2.241023] lije systemd-networkd[356]: qemu: flags change: +LOWER_UP [2.241121] lije systemd-networkd[356]: qemu: gained carrier [3.316936] lije systemd-networkd[356]: qemu: added address: fe80::18de:adff:febe:ef01/64 (There is a service in the background that changes the MAC address of the qemu interface, that's why it changes). As you can see, there is no indication of either enp3s0 or lo. Now, if I bring enp3s0 up manually (ip link set dev enp3s0 up), this happens: [ 68.472579] lije systemd-networkd[356]: enp3s0 : link 2 added [ 68.472864] lije systemd-networkd[356]: enp3s0 : udev initialized link [ 68.473060] lije systemd-networkd[356]: enp3s0 : flags change: +UP +MULTICAST +BROADCAST [ 68.473242] lije systemd-networkd[356]: enp3s0 : link state is up-to-date [ 68.473429] lije systemd-networkd[356]: enp3s0 : found matching network '/etc/systemd/network/01-lan.network' [ 68.473578] lije systemd-networkd[356]: enp3s0 : enslaved [ 68.473718] lije systemd-networkd[356]: enp3s0 : setting addresses [ 68.473854] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [ 68.473988] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [ 68.474137] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [ 68.474275] lije systemd-networkd[356]: enp3s0 : added address: 10.23.42.4/26 [ 68.474424] lije systemd-networkd[356]: enp3s0 : addresses set [ 68.474565] lije systemd-networkd[356]: enp3s0 : setting routes [ 68.474975] lije systemd-networkd[356]: enp3s0 : routes set [ 68.475132] lije systemd-networkd[356]: enp3s0 : link configured [ 70.054677] lije systemd-networkd[356]: enp3s0 :
Re: [systemd-devel] start / stop daemon
On Tue, Aug 19, 2014 at 5:44 PM, Bonno Bloksma b.blok...@tio.nl wrote: Hi, I do not know whether this is something systemd should handle or if it is something that belongs to the kernel, so let me ask this first: Is starting and stopping a daemon part of something systemd is / becomes responsible for? Well, yes, starting stopping daemons is pretty much the *primary function* of systemd; it's part of the job of being an init system. (Although the old SysVinit would rather delegate this to shellscripts.) The kernel still manages individual processes (fork/exec/exit), of course; but it's not the kernel's job to care about what is a 'daemon' nor what daemons should be started when. In that case I would like to ask if the developers have already considered a development in the Windows world considering the stopping of services that may take a LOOONG time stopping, for instance some databases. I wonder if the people developing systemd are paying attention to a development in de Windows environment where the latest thing is that de service can report back that it is indeed still trying to stop and not just hung or not reporting back. Windows will now kill a service after a certain time when shutting down, in some cases it is killing a database that took A LONG TIME to shut down and cause the database to become inconsistent. The new development is to make sure that does not happen. If systemd is trying to become smart about stopping services it might be a good idea to have this built in. Also not just have the service report back I am still busy but also with a progress indicator which NEEDS to increase at each report so systemd can detect whether the service is indeed progressing towards a stopped state or hung in the getting there. From the past I have seen things go wrong in communication when the only thing reported back is I am busy while there was no progress being made toward the finish. Is this something the systemd team has already put on the todo list or am I the first to suggest it? Possibly: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/21419 http://article.gmane.org/gmane.comp.sysutils.systemd.devel/21997 Introducing sd_notify() messages that can notify PID 1 about daemons reloading or shutting down, has been on the TODO list for a while -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Using path name in instantiated units
Hello, I have a systemd unit that should do a commit on a specific path. Since there are more then one path / repos, I want to use an instantiated unit for that (the stuff with @ in the unit name): ~/.config/systemd/user % cat git-commit@.service [Unit] Description=Auto commit for instance. [Service] Type = oneshot Nice = 10 # git returns 1 if there is nothing to commit SuccessExitStatus=1 WorkingDirectory = %I # also tried %i ExecStart = /usr/bin/sh -c 'echo %i wd' ExecStart = /usr/bin/sh -c 'echo %i wd' ExecStart = /usr/bin/sh -c 'echo `pwd` wd' ExecStart = /usr/bin/git add --all . ExecStart = /usr/bin/git commit -a -m Automatic commit. It seems that using %i or %I to set the working directory does not work. When I do systemctl --user start git-commit@/home/florian/timer.test.service the journal prints: Aug 19 18:43:01 asaru systemd[375]: Starting Auto commit for instance Aug 19 18:43:01 asaru git[4761]: fatal: Not a git repository (or any of the parent directories): .git Aug 19 18:43:01 asaru systemd[375]: git-commit@-home-florian- timer.test.service: main process exited, code=exited, status=128/n/a Aug 19 18:43:01 asaru systemd[375]: Failed to start Auto commit for instance.. Aug 19 18:43:01 asaru systemd[375]: Unit git-commit@-home-florian- timer.test.service entered failed state. and wd (created in ~) contains -home-florian-timer.test -home-florian-timer.test /home/florian Any ideas how I can change the working directory to the directory given by the instance name? Thx! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using path name in instantiated units
В Tue, 19 Aug 2014 19:34:46 +0200 Florian Lindner mailingli...@xgm.de пишет: It seems that using %i or %I to set the working directory does not work. bor@opensuse:~ sudo systemctl start foo@/home/bor.service bor@opensuse:~ cat /tmp/foo /home/bor %i=-home-bor %I=/home/bor bor@opensuse:~ cat /run/systemd/system/foo@.service [Unit] Description=Path %i (%I) [Service] Type=oneshot WorkingDirectory=%I ExecStart=/bin/sh -c '/bin/pwd /tmp/foo; echo %%i=%i /tmp/foo; echo %%I=%I /tmp/foo' When I do systemctl --user start git-commit@/home/florian/timer.test.service the journal prints: Aug 19 18:43:01 asaru systemd[375]: Starting Auto commit for instance Aug 19 18:43:01 asaru git[4761]: fatal: Not a git repository (or any of the parent directories): .git Aug 19 18:43:01 asaru systemd[375]: git-commit@-home-florian- timer.test.service: main process exited, code=exited, status=128/n/a Aug 19 18:43:01 asaru systemd[375]: Failed to start Auto commit for instance.. Aug 19 18:43:01 asaru systemd[375]: Unit git-commit@-home-florian- timer.test.service entered failed state. and wd (created in ~) contains -home-florian-timer.test -home-florian-timer.test /home/florian Any ideas how I can change the working directory to the directory given by the instance name? Thx! ___ 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] Using path name in instantiated units
Andrei Borzenkov wrote: В Tue, 19 Aug 2014 19:34:46 +0200 Florian Lindner mailingli...@xgm.de пишет: It seems that using %i or %I to set the working directory does not work. bor@opensuse:~ sudo systemctl start foo@/home/bor.service bor@opensuse:~ cat /tmp/foo /home/bor %i=-home-bor %I=/home/bor bor@opensuse:~ cat /run/systemd/system/foo@.service [Unit] Description=Path %i (%I) [Service] Type=oneshot WorkingDirectory=%I ExecStart=/bin/sh -c '/bin/pwd /tmp/foo; echo %%i=%i /tmp/foo; echo %%I=%I /tmp/foo' Ok, somehow I obviously got confused while testing. Sorry! I also try to set up a matching timer: systemctl --user start git-commit@/home/florian/timer.test.timer works fine, but: systemctl --user enable git-commit@/home/florian/timer.test.timer Failed to execute operation: Invalid argument Or is creating a target for the timer and set WantedBy in the service file the way to go? But still, why is starting working, but not enabling? Thx, Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using path name in instantiated units
В Tue, 19 Aug 2014 20:59:55 +0200 Florian Lindner mailingli...@xgm.de пишет: I also try to set up a matching timer: systemctl --user start git-commit@/home/florian/timer.test.timer works fine, but: systemctl --user enable git-commit@/home/florian/timer.test.timer Failed to execute operation: Invalid argument Or is creating a target for the timer and set WantedBy in the service file the way to go? But still, why is starting working, but not enabling? Does your unit have [Install] section? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: add -t --identifier=STRING option
2014-08-19 12:12 GMT+02:00 har...@redhat.com:
From: Harald Hoyer har...@redhat.com
This turns journalctl to the counterpart of systemd-cat.
Messages sent with
systemd-cat --identifier foo --prioritiy debug
can now be shown with
journalctl --identifier foo --prioritiy debug
--identifier is not merged with --unit to make a clear
distinction between syslog and systemd units.
syslog identifiers can be chosen freely by anyone.
---
man/journalctl.xml | 14 ++
src/journal/journalctl.c | 43 ++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/man/journalctl.xml b/man/journalctl.xml
index bf18756..906ffd0 100644
--- a/man/journalctl.xml
+++ b/man/journalctl.xml
@@ -498,6 +498,20 @@
/varlistentry
varlistentry
+termoption-t/option/term
+
termoption--identifier=replaceableSYSLOG_IDENTIFIER/replaceable|replaceablePATTERN/replaceable/option/term
+
+listitemparaShow messages for the
+specified syslog identifier
+
replaceableSYSLOG_IDENTIFIER/replaceable, or
+for any of the messages with a
literalSYSLOG_IDENTIFIER/literal
+matched by
replaceablePATTERN/replaceable./para
+
+paraThis parameter can be specified
+multiple times./para/listitem
+/varlistentry
+
+varlistentry
termoption-u/option/term
termoption--unit=replaceableUNIT/replaceable|replaceablePATTERN/replaceable/option/term
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 5c4a71d..3037fb8 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -89,6 +89,7 @@ static bool arg_force = false;
#endif
static usec_t arg_since, arg_until;
static bool arg_since_set = false, arg_until_set = false;
+static char **arg_syslog_identifier = NULL;
static char **arg_system_units = NULL;
static char **arg_user_units = NULL;
static const char *arg_field = NULL;
@@ -180,6 +181,7 @@ static void help(void) {
-k --dmesg Show kernel message log from the
current boot\n
-u --unit=UNIT Show data only from the specified
unit\n
--user-unit=UNIT Show data only from the specified
user session unit\n
+ -t --identifier=STRING Show only messages wit the
specified syslog identifier\n
with*
-p --priority=RANGE Show only messages within the
specified priority range\n
-e --pager-end Immediately jump to end of the
journal in the pager\n
-f --follow Follow the journal\n
@@ -276,6 +278,7 @@ static int parse_argv(int argc, char *argv[]) {
{ file, required_argument, NULL, ARG_FILE
},
{ root, required_argument, NULL, ARG_ROOT
},
{ header, no_argument, NULL, ARG_HEADER
},
+{ identifier, required_argument, NULL, 't'
},
{ priority, required_argument, NULL, 'p'
},
{ setup-keys, no_argument, NULL, ARG_SETUP_KEYS
},
{ interval, required_argument, NULL, ARG_INTERVAL
},
@@ -304,7 +307,7 @@ static int parse_argv(int argc, char *argv[]) {
assert(argc = 0);
assert(argv);
-while ((c = getopt_long(argc, argv,
hefo:aln::qmb::kD:p:c:u:F:xrM:, options, NULL)) = 0)
+while ((c = getopt_long(argc, argv,
hefo:aln::qmb::kD:p:c:t:u:F:xrM:, options, NULL)) = 0)
switch (c) {
@@ -590,6 +593,12 @@ static int parse_argv(int argc, char *argv[]) {
arg_until_set = true;
break;
+case 't':
+r = strv_extend(arg_syslog_identifier, optarg);
+if (r 0)
+return log_oom();
+break;
+
case 'u':
r = strv_extend(arg_system_units, optarg);
if (r 0)
@@ -1212,6 +1221,32 @@ static int add_priorities(sd_journal *j) {
return 0;
}
+
+static int add_syslog_identifier(sd_journal *j) {
+int r;
+char **i;
+
+assert(j);
+
+STRV_FOREACH(i, arg_syslog_identifier) {
+char *u;
+
+u = strappenda(SYSLOG_IDENTIFIER=, *i);
+r = sd_journal_add_match(j, u, 0);
+
[systemd-devel] Suppressing automounting
(This is more proper for a systemd-users mailing list, but I can't find one.) I'd like to customize my systemd. (I'm running Fedora Linux 19, with systemd-204-20.fc19.x86_64.) I have a line in /etc/fstab like this, which refers to a logical volume on a USB storage device: /dev/Freeze02/Store2/Store2ext4 nofail,defaults 0 0 Of course, if the logical folume Store2 is present at boot time, it gets mounted. In the past, once the system is running, if I plug in the storage device, the volume does not get mounted unless I manuall issue mount /Store2. More recently, if I plug in the storage device, the volume gets mounted automatically. Messages in /var/log/messages suggest that systemd is doing the mounting. I would like to suppress the latter automatic mounting. (This is for all filesystems, which means I don't want to have to modify every fstab line.) The documentation of systemd is voluminous and hard to understand, but I believe that in order to do this, I need to provide systemd with a value that applies to all *.automount units that suppresses the action of the unit. Because I do not want to put noauto in the fstab line, I expect that the initial mounting will still be done if the logical volume is present at boot time. I'm guessing that putting something in a automount@.service file will suffice. Does anyone have any advice? Thanks, Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using path name in instantiated units
Andrei Borzenkov wrote: В Tue, 19 Aug 2014 20:59:55 +0200 Florian Lindner mailingli...@xgm.de пишет: I also try to set up a matching timer: systemctl --user start git-commit@/home/florian/timer.test.timer works fine, but: systemctl --user enable git-commit@/home/florian/timer.test.timer Failed to execute operation: Invalid argument Or is creating a target for the timer and set WantedBy in the service file the way to go? But still, why is starting working, but not enabling? Does your unit have [Install] section? No. This was my latter idea, creating a target and set WantedBy=that.target in the services [Install] section. Not? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using path name in instantiated units
On Tuesday, August 19, 2014 07:34:46 PM Florian Lindner wrote:
Any ideas how I can change the working directory to the directory given by
the instance name?
I do something like this to rebuild Jekyll sites based on a git commit. Maybe
this will help you.
1. A path unit watches for changes to refs/heads/master
[Unit]
Description=Jekyll Static Website Builder Watch for %i
ConditionPathExists=/var/lib/git/%i.git/refs/heads/master
[Path]
PathModified=/var/lib/git/%i.git/refs/heads/master
[Install]
Alias=jekyll-build@%i.path
WantedBy=multi-user.target
2. If the path unit is triggered, the corresponding service unit starts
[Unit]
Description=Jekyll Static Website Builder for %i
[Service]
Type=oneshot
Nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/usr/sbin/jekyll-build %i
PrivateTmp=true
3. In my case, the Bash script it executes, dumps all of the sites into one
directory, but you could easily change the script to dump them in various
places, but you'd probably need to change the instantiated units to something
like jekyll-build@my-sub-path-here and replace - with / in the Bash
script itself.
#!/usr/bin/bash
dest=/var/www/${1}
repo=/var/git/${1}.git
scratch=$(mktemp --directory)
git clone $repo $scratch
jekyll build --verbose --trace --source $scratch --destination $dest
rm -fr $scratch
exit 0
--
Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E
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] Suppressing automounting
On Tue, 19.08.14 15:56, Dale R. Worley (wor...@alum.mit.edu) wrote: (This is more proper for a systemd-users mailing list, but I can't find one.) I'd like to customize my systemd. (I'm running Fedora Linux 19, with systemd-204-20.fc19.x86_64.) I have a line in /etc/fstab like this, which refers to a logical volume on a USB storage device: /dev/Freeze02/Store2 /Store2ext4 nofail,defaults 0 0 Of course, if the logical folume Store2 is present at boot time, it gets mounted. This is not really what nofail means in a systemd context. It just means that we won't delay the boot process for this device to show up. This means that the device will be mounted as it shows up but we won't wait for it at boot. To turn off automatic mounting of the device, you need to use noauto instead. Note that a concept of mount at boot if it is there, otherwise don't cannot work. The problem here is that most modern storage devices can take any time they want to initialize and we simply have no idea how long to wait for them. Because of that we just wait for the file systems listed in /etc/fstab and immediately continue. Especially on USB there's no point in time known where all devices have to have reported back to the OS, they can take any time they want. (For the most extreme case, think of Android devices, which when plugged into a PC actually require confirmation on the device before the device shows up!) In the past, once the system is running, if I plug in the storage device, the volume does not get mounted unless I manuall issue mount /Store2. More recently, if I plug in the storage device, the volume gets mounted automatically. Messages in /var/log/messages suggest that systemd is doing the mounting. Correct. I would like to suppress the latter automatic mounting. (This is for all filesystems, which means I don't want to have to modify every fstab line.) Well, this is not possible with the current logic. You have three choices: a) not mount it at all by default (noauto) b) wait for it at boot and mount it (default) c) don't wait for it, but mount it as it shows up (nofail) As mentioned an option d) of mount it if it is around at boot, but not later is not available, since the idea is not compatible with modern storage. The documentation of systemd is voluminous and hard to understand, but I believe that in order to do this, I need to provide systemd with a value that applies to all *.automount units that suppresses the action of the unit. Because I do not want to put noauto in the fstab line, I expect that the initial mounting will still be done if the logical volume is present at boot time. I'm guessing that putting something in a automount@.service file will suffice. The .automount units actually are about something slightly different: they are a way how you can establish mount points without actually backing them immediately with a file system, but simply delaying that until the first access. They implement what autofs4 or amd do, too. It is not directly related to what you are trying to do. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] start / stop daemon
On Tue, 19.08.14 14:44, Bonno Bloksma (b.blok...@tio.nl) wrote: I wonder if the people developing systemd are paying attention to a development in de Windows environment where the latest thing is that de service can report back that it is indeed still trying to stop and not just hung or not reporting back. Windows will now kill a service after a certain time when shutting down, in some cases it is killing a database that took A LONG TIME to shut down and cause the database to become inconsistent. The new development is to make sure that does not happen. If systemd is trying to become smart about stopping services it might be a good idea to have this built in. Also not just have the service report back I am still busy but also with a progress indicator which NEEDS to increase at each report so systemd can detect whether the service is indeed progressing towards a stopped state or hung in the getting there. From the past I have seen things go wrong in communication when the only thing reported back is I am busy while there was no progress being made toward the finish. I am not sure I understand what the big benefit of having an overall stop timeout applied (as we already have) is? What's on the TODO list is that a service can actually let systemd know when it shuts down. Currently systemd knows that only if it is the one requesting the shutdown. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using path name in instantiated units
On Tue, 19.08.14 19:34, Florian Lindner (mailingli...@xgm.de) wrote: Hello, I have a systemd unit that should do a commit on a specific path. Since there are more then one path / repos, I want to use an instantiated unit for that (the stuff with @ in the unit name): ~/.config/systemd/user % cat git-commit@.service [Unit] Description=Auto commit for instance. [Service] Type = oneshot Nice = 10 # git returns 1 if there is nothing to commit SuccessExitStatus=1 WorkingDirectory = %I # also tried %i ExecStart = /usr/bin/sh -c 'echo %i wd' ExecStart = /usr/bin/sh -c 'echo %i wd' ExecStart = /usr/bin/sh -c 'echo `pwd` wd' ExecStart = /usr/bin/git add --all . ExecStart = /usr/bin/git commit -a -m Automatic commit. Use %f for unescaping paths. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: fix typos
--- man/journalctl.xml| 6 +++--- man/systemctl.xml | 2 +- man/systemd-firstboot.xml | 4 ++-- man/systemd.network.xml | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/man/journalctl.xml b/man/journalctl.xml index bf18756..e10918a 100644 --- a/man/journalctl.xml +++ b/man/journalctl.xml @@ -99,9 +99,9 @@ literal_KERNEL_DEVICE=/literal match for the device./para -paraAdditional contraints may be added using options +paraAdditional constraints may be added using options option--boot/option, option--unit=/option, -etc, to futher limit what entries will be shown +etc, to further limit what entries will be shown (logical AND)./para paraOutput is interleaved from all accessible @@ -128,7 +128,7 @@ option--no-pager/option option and the Environment section below./para -paraWhen outputing to a tty, lines are colored +paraWhen outputting to a tty, lines are colored according to priority: lines of level ERROR and higher are colored red; lines of level NOTICE and higher are highlighted; other lines are displayed normally. diff --git a/man/systemctl.xml b/man/systemctl.xml index db7798d..2818bcb 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1305,7 +1305,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service listitem paraChecks whether the system is running. This returns success when the system is fully up and running, meaning -not in startup, shutdown or maintainance mode. Failure is +not in startup, shutdown or maintenance mode. Failure is returned otherwise. In addition, the current state is printed in a short string to standard output. Use option--quiet/option to suppress output of this state diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml index c3fe0ed..5da0a75 100644 --- a/man/systemd-firstboot.xml +++ b/man/systemd-firstboot.xml @@ -213,7 +213,7 @@ paraQuery the user for locale, timezone, hostname and root password. This is equivalent to -specifiying +specifying option--prompt-locale/option, option--prompt-timezone/option, option--prompt-hostname/option, @@ -238,7 +238,7 @@ paraCopy locale, time zone and root password from the host. This is -equivalent to specifiying +equivalent to specifying option--copy-locale/option, option--copy-timezone/option, option--copy-root-password/option diff --git a/man/systemd.network.xml b/man/systemd.network.xml index 0245099..641e02a 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -412,7 +412,7 @@ termvarnameDestination=/varname/term listitem paraThe destination prefix of the route. Possibly followed by a slash and the -prefixlength. If ommitted, a full-length host route is assumed./para +prefixlength. If omitted, a full-length host route is assumed./para /listitem /varlistentry varlistentry -- 2.0.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Do not mount /run a second time when using smack
From: Philippe De Swert philippedesw...@gmail.com Hi, Going through the code trying to learn how systemd exactly works and try to understand the mounting better, hunting down some weird mount related bug I came across something that did not look right. If I understood things right, basic filesystems get mounted one at a time by looping through the mount_table one by one (with mount_one). Now it seems that in the case smack is enabled /run will get mounted twice. I could not immediately find specific info about smack related to /run but it does not seem very sensible to mount another tmpfs instance on /run hiding the smack one. Cheers, Philippe Philippe De Swert (1): [mount] Do not try to mount /run a second time when using smack src/core/mount-setup.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.8.1.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] [mount] Do not try to mount /run a second time when using smack
From: Philippe De Swert philippedesw...@gmail.com
Smack mounts /run with some different parameters, we definitely
do not want to have a second mount over it afterwards
Signed-off-by: Philippe De Swert philippedesw...@gmail.com
---
src/core/mount-setup.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index cc2633e..f87390b 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -93,9 +93,10 @@ static const MountPoint mount_table[] = {
#ifdef HAVE_SMACK
{ tmpfs, /run, tmpfs,
mode=755,smackfsroot=*, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
use_smack, MNT_FATAL },
-#endif
+#else
{ tmpfs, /run, tmpfs, mode=755,
MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
+#endif
{ tmpfs, /sys/fs/cgroup,tmpfs, mode=755,
MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ cgroup, /sys/fs/cgroup/systemd,cgroup,
none,name=systemd,xattr, MS_NOSUID|MS_NOEXEC|MS_NODEV,
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] bootchart: use NSEC_PER_SEC
Maybe these are candidates for this as well?
src/bootchart/bootchart.c:355:interval = (1.0 / arg_hz) * 10.0;
src/bootchart/bootchart.c:413:elapsed = (sample_stop -
sampledata-sampletime) * 10.0;
src/bootchart/bootchart.c:416:newint_s =
(time_t)(timeleft / 10.0);
src/bootchart/bootchart.c:417:newint_ns =
(long)(timeleft - (newint_s * 10.0));
src/bootchart/svg.c:634:max / 1024.0 /
(interval / 10.0));
src/bootchart/svg.c:743:max / 1024.0 /
(interval / 10.0));
src/bootchart/svg.c:770:trt = trt / 10.0;
src/bootchart/svg.c:812:twt = twt / 10.0;
src/bootchart/svg.c:1064:prt = (rt /
10) / (ps-sample-sampledata-sampletime -
prev-sampledata-sampletime);
src/bootchart/svg.c:1065:wrt = (wt /
10) / (ps-sample-sampledata-sampletime -
prev-sampledata-sampletime);
src/bootchart/svg.c:1104:(ps-last-runtime -
ps-first-runtime) / 10.0,
src/bootchart/store.c:413:/ 10.0;
src/cgtop/cgtop.c:179:x = ((uint64_t)
ts.tv_sec * 10ULL + (uint64_t) ts.tv_nsec) -
src/cgtop/cgtop.c:180:((uint64_t)
g-cpu_timestamp.tv_sec * 10ULL + (uint64_t)
g-cpu_timestamp.tv_nsec);
src/cgtop/cgtop.c:264:x = ((uint64_t)
ts.tv_sec * 10ULL + (uint64_t) ts.tv_nsec) -
src/cgtop/cgtop.c:265:((uint64_t)
g-io_timestamp.tv_sec * 10ULL + (uint64_t)
g-io_timestamp.tv_nsec);
src/cgtop/cgtop.c:271:g-io_input_bps
= (yr * 10ULL) / x;
src/cgtop/cgtop.c:272:g-io_output_bps
= (yw * 10ULL) / x;
On Mon, Aug 18, 2014 at 8:59 PM, Ronny Chevalier
chevalier.ro...@gmail.com wrote:
---
src/bootchart/store.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/bootchart/store.c b/src/bootchart/store.c
index cedcba8..2d2ea42 100644
--- a/src/bootchart/store.c
+++ b/src/bootchart/store.c
@@ -34,6 +34,7 @@
#include time.h
#include util.h
+#include time-util.h
#include strxcpyx.h
#include store.h
#include bootchart.h
@@ -54,14 +55,14 @@ double gettime_ns(void) {
clock_gettime(CLOCK_MONOTONIC, n);
-return (n.tv_sec + (n.tv_nsec / 10.0));
+return (n.tv_sec + (n.tv_nsec / (double) NSEC_PER_SEC));
}
static double gettime_up(void) {
struct timespec n;
clock_gettime(CLOCK_BOOTTIME, n);
-return (n.tv_sec + (n.tv_nsec / 10.0));
+return (n.tv_sec + (n.tv_nsec / (double) NSEC_PER_SEC));
}
void log_uptime(void) {
--
2.0.4
___
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] [PATCH] man: fix typos
On 08/19/2014 11:21 PM, Ronny Chevalier wrote: --- man/journalctl.xml| 6 +++--- man/systemctl.xml | 2 +- man/systemd-firstboot.xml | 4 ++-- man/systemd.network.xml | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) Applied, thanks! diff --git a/man/journalctl.xml b/man/journalctl.xml index bf18756..e10918a 100644 --- a/man/journalctl.xml +++ b/man/journalctl.xml @@ -99,9 +99,9 @@ literal_KERNEL_DEVICE=/literal match for the device./para -paraAdditional contraints may be added using options +paraAdditional constraints may be added using options option--boot/option, option--unit=/option, -etc, to futher limit what entries will be shown +etc, to further limit what entries will be shown (logical AND)./para paraOutput is interleaved from all accessible @@ -128,7 +128,7 @@ option--no-pager/option option and the Environment section below./para -paraWhen outputing to a tty, lines are colored +paraWhen outputting to a tty, lines are colored according to priority: lines of level ERROR and higher are colored red; lines of level NOTICE and higher are highlighted; other lines are displayed normally. diff --git a/man/systemctl.xml b/man/systemctl.xml index db7798d..2818bcb 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -1305,7 +1305,7 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service listitem paraChecks whether the system is running. This returns success when the system is fully up and running, meaning -not in startup, shutdown or maintainance mode. Failure is +not in startup, shutdown or maintenance mode. Failure is returned otherwise. In addition, the current state is printed in a short string to standard output. Use option--quiet/option to suppress output of this state diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml index c3fe0ed..5da0a75 100644 --- a/man/systemd-firstboot.xml +++ b/man/systemd-firstboot.xml @@ -213,7 +213,7 @@ paraQuery the user for locale, timezone, hostname and root password. This is equivalent to -specifiying +specifying option--prompt-locale/option, option--prompt-timezone/option, option--prompt-hostname/option, @@ -238,7 +238,7 @@ paraCopy locale, time zone and root password from the host. This is -equivalent to specifiying +equivalent to specifying option--copy-locale/option, option--copy-timezone/option, option--copy-root-password/option diff --git a/man/systemd.network.xml b/man/systemd.network.xml index 0245099..641e02a 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -412,7 +412,7 @@ termvarnameDestination=/varname/term listitem paraThe destination prefix of the route. Possibly followed by a slash and the -prefixlength. If ommitted, a full-length host route is assumed./para +prefixlength. If omitted, a full-length host route is assumed./para /listitem /varlistentry varlistentry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] bootchart: use NSEC_PER_SEC
On Tue, 19.08.14 23:31, Thomas H.P. Andersen (pho...@gmail.com) wrote: Maybe these are candidates for this as well? src/bootchart/bootchart.c:355:interval = (1.0 / arg_hz) * 10.0; src/bootchart/bootchart.c:413:elapsed = (sample_stop - sampledata-sampletime) * 10.0; src/bootchart/bootchart.c:416:newint_s = (time_t)(timeleft / 10.0); src/bootchart/bootchart.c:417:newint_ns = (long)(timeleft - (newint_s * 10.0)); src/bootchart/svg.c:634:max / 1024.0 / (interval / 10.0)); src/bootchart/svg.c:743:max / 1024.0 / (interval / 10.0)); src/bootchart/svg.c:770:trt = trt / 10.0; src/bootchart/svg.c:812:twt = twt / 10.0; src/bootchart/svg.c:1064:prt = (rt / 10) / (ps-sample-sampledata-sampletime - prev-sampledata-sampletime); src/bootchart/svg.c:1065:wrt = (wt / 10) / (ps-sample-sampledata-sampletime - prev-sampledata-sampletime); src/bootchart/svg.c:1104:(ps-last-runtime - ps-first-runtime) / 10.0, src/bootchart/store.c:413:/ 10.0; src/cgtop/cgtop.c:179:x = ((uint64_t) ts.tv_sec * 10ULL + (uint64_t) ts.tv_nsec) - src/cgtop/cgtop.c:180:((uint64_t) g-cpu_timestamp.tv_sec * 10ULL + (uint64_t) g-cpu_timestamp.tv_nsec); src/cgtop/cgtop.c:264:x = ((uint64_t) ts.tv_sec * 10ULL + (uint64_t) ts.tv_nsec) - src/cgtop/cgtop.c:265:((uint64_t) g-io_timestamp.tv_sec * 10ULL + (uint64_t) g-io_timestamp.tv_nsec); src/cgtop/cgtop.c:271:g-io_input_bps = (yr * 10ULL) / x; src/cgtop/cgtop.c:272:g-io_output_bps = (yw * 10ULL) / x; The cgtop/bps ones are weird. But the other ones definitely. Actually, I wished bootchart wouldn#t use floats for its timekeeping, but just usec_t like everything else. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [mount] Do not try to mount /run a second time when using smack
On Wed, 20.08.14 00:29, Philippe De Swert (philippedesw...@gmail.com) wrote: From: Philippe De Swert philippedesw...@gmail.com Smack mounts /run with some different parameters, we definitely do not want to have a second mount over it afterwards Nah, it's not actually mounted twice. The idea here is that a SMACK-enabled systemd also works on SMACK-less kernels. Hence we first try mounting with the smackfsroot=* switch (which will fail on SMACK-less kernels, and then fallback to the same line without the option. Note that the second line is marked with MNT_FATAL, to indicate that that's the line we *really* need. Also note that the actual mount code will always check if there's already a mount point in place, and in that case simply skip any further mounting. We do that in particulary to be able to handle the cases where some initrd is already passing in some file systems pre-mounted. So, everything's alright in the current code afaics. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 216
Heya! This is a major new release. Among many other changes systemd-resolved is now a pretty complete caching DNS and LLMNR stub resolver. http://www.freedesktop.org/software/systemd/systemd-216.tar.xz CHANGES WITH 216: * timedated no longer reads NTP implementation unit names from /usr/lib/systemd/ntp-units.d/*.list. Alternative NTP implementations should add a Conflicts=systemd-timesyncd.service to their unit files to take over and replace systemd's NTP default functionality. * systemd-sysusers gained a new line type r for configuring which UID/GID ranges to allocate system users/groups from. Lines of type u may now add an additional column that specifies the home directory for the system user to be created. Also, systemd-sysusers may now optionally read user information from STDIN instead of a file. This is useful for invoking it from RPM preinst scriptlets that need to create users before the first RPM file is installed since these files might need to be owned by them. A new %sysusers_create_inline RPM macro has been introduced to do just that. systemd-sysusers now updates the shadow files as well as the user/group databases, which should enhance compatibility with certain tools like grpck. * A number of bus APIs of PID 1 now optionally consult PolicyKit to permit access for otherwise unprivileged clients under certain conditions. Note that this currently doesn't support interactive authentication yet, but this is expected to be added eventually, too. * /etc/machine-info now has new fields for configuring the deployment environment of the machine, as well as the location of the machine. hostnamectl has been updated with new command to update these fields. * systemd-timesyncd has been updated to automatically acquire NTP server information from systemd-networkd, which might have been discovered via DHCP. * systemd-resolved now includes a caching DNS stub resolver and a complete LLMNR name resolution implementation. A new NSS module nss-resolve has been added which make be used of glibc's own nss-dns to resolve hostnames via systemd-resolved. Hostnames, addresses and arbitrary RRs may be resolved via systemd-resolved D-Bus APIs. In contrast to the glibc internal resolver systemd-resolved is aware of multi-homed system, and keeps DNS server and caches separate and per-interface. Queries are sent simultaneously on all interfaces that have DNS servers configured, in order to properly handle VPNs and local LANs which might resolve separate sets of domain names. systemd-resolved may acquire DNS server information from systemd-networkd automatically, which in turn might have discovered them via DHCP. A tool systemd-resolve-host has been added that may be used to query the DNS logic in resolved. systemd-resolved implements IDNA and automatically uses IDNA or UTF-8 encoding depending on whether classic DNS or LLMNR is used as transport. In the next releases we intend to add a DNSSEC and mDNS/DNS-SD implementation to systemd-resolved. * A new NSS module nss-mymachines has been added, that automatically resolves the names of all local registered containers to their respective IP addresses. * A new client tool networkctl for systemd-networkd has been added. It currently is entirely passive and will query networking configuration from udev, rtnetlink and networkd, and present it to the user in a very friendly way. Eventually, we hope to extend it to become a full control utility for networkd. * .socket units gained a new DeferAcceptSec= setting that controls the kernels' TCP_DEFER_ACCEPT sockopt for TCP. Similar, support for controlling TCP keep-alive settings has been added (KeepAliveTimeSec=, KeepAliveIntervalSec=, KeepAliveProbes=). Also, support for turning off Nagle's algorithm on TCP has been added (NoDelay=). * logind learned a new session type web, for use in projects like Cockpit which register web clients as PAM sessions. * timer units with at least one OnCalendar= setting will now be started only after timer-sync.target has been reached. This way they will not elapse before the system clock has been corrected by a local NTP client or similar. This is particular useful on RTC-less embedded machines, that come up with an invalid system clock. * systemd-nspawn's
Re: [systemd-devel] Using path name in instantiated units
В Tue, 19 Aug 2014 22:54:04 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 19.08.14 19:34, Florian Lindner (mailingli...@xgm.de) wrote: Hello, I have a systemd unit that should do a commit on a specific path. Since there are more then one path / repos, I want to use an instantiated unit for that (the stuff with @ in the unit name): ~/.config/systemd/user % cat git-commit@.service [Unit] Description=Auto commit for instance. [Service] Type = oneshot Nice = 10 # git returns 1 if there is nothing to commit SuccessExitStatus=1 WorkingDirectory = %I # also tried %i ExecStart = /usr/bin/sh -c 'echo %i wd' ExecStart = /usr/bin/sh -c 'echo %i wd' ExecStart = /usr/bin/sh -c 'echo `pwd` wd' ExecStart = /usr/bin/git add --all . ExecStart = /usr/bin/git commit -a -m Automatic commit. Use %f for unescaping paths. Actually this will give incorrect result. If you call it foo@/path/to/file, instance gets escaped into -path-to-file; prepending / to unescaped instance results in //path/to/file. Not fatal, but some programs may misinterpret initial //. %I works just fine here. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Using path name in instantiated units
В Tue, 19 Aug 2014 22:08:26 +0200 Florian Lindner mailingli...@xgm.de пишет: Andrei Borzenkov wrote: В Tue, 19 Aug 2014 20:59:55 +0200 Florian Lindner mailingli...@xgm.de пишет: I also try to set up a matching timer: systemctl --user start git-commit@/home/florian/timer.test.timer works fine, but: systemctl --user enable git-commit@/home/florian/timer.test.timer Failed to execute operation: Invalid argument Or is creating a target for the timer and set WantedBy in the service file the way to go? But still, why is starting working, but not enabling? Does your unit have [Install] section? No. systemctl enable creates links listed in [Install] section; how do expect it to work in this case? This was my latter idea, creating a target and set WantedBy=that.target in the services [Install] section. Not? Yes (it may be any unit, not necessarily target). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 216
Hi, On Wed, Aug 20, 2014 at 02:59:52AM +0200, Lennart Poettering wrote: Heya! This is a major new release. Among many other changes systemd-resolved is now a pretty complete caching DNS and LLMNR stub resolver. http://www.freedesktop.org/software/systemd/systemd-216.tar.xz CHANGES WITH 216: * A new tool systemd-journal-upload has been added to push journal data to a remote system running systemd-journal-remote. The sysusers.d file shipped with this has: u systemd-journal-remote- systemd Journal Remote But the tmpfiles.d fragment has: z /var/log/journal/remote 2755 root systemd-journal-remote - - z /run/log/journal/remote 2755 root systemd-journal-remote - - There's no systemd-journal-remote group created... * A new component systemd-firstboot has been added that queries the most basic systemd information (timezone, hostname, root password) interactively on first boot. Alternatively it may also be used to provision these things offline on OS images installed into directories. This tool offers a --setup-machine-id flag, but it has very different semantics from systemd-machine-id-setup. Both will call sd128_randomize, but systemd-machine-id-setup will always prefer hardcoded UUIDs passed into the host. For example, launching a qemu kvm with the -uuid flag will cause the machine-id to mirror this -- though, this alone can be problematic[1] Is this behavior intentional? Does firstboot need to learn the same rules? Do we just retire systemd-machine-id-setup? Cheers, d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 216
В Wed, 20 Aug 2014 02:59:52 +0200 Lennart Poettering lenn...@poettering.net пишет: Heya! This is a major new release. Among many other changes systemd-resolved is now a pretty complete caching DNS and LLMNR stub resolver. http://www.freedesktop.org/software/systemd/systemd-216.tar.xz CHANGES WITH 216: * timedated no longer reads NTP implementation unit names from /usr/lib/systemd/ntp-units.d/*.list. Alternative NTP implementations should add a Conflicts=systemd-timesyncd.service to their unit files to take over and replace systemd's NTP default functionality. Does it mean any alternative service should also declare Alias=systemd-timesyncd.service? This is what timedated checks to answer whether NTP is enabled. * systemd will no longer inform the kernel about the current timezone, as this is necessarily incorrect and racy as the kernel has no understanding of DST and similar concepts. This hence means FAT timestamps will be always considered UTC, similar to what Android is already doing. Also, when the RTC is configured to the local time (rather than UTC) systemd will never synchronize back to it, as this might confuse Windows at a later boot. I do not know how often Android users need to exchange data with Windows via USB stick, but I have to do it pretty often and it sounds like now my timestamps will be wrong. Could you please name commit that does it? The only one I can find close to it (c264aeab4b0e7b69f469e12e78d4a48b3ed7a66e) says actually core: only set the kernel's timezone when the RTC runs in local time which is quite different. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] udev: do NOT re-label smack
If selinux is disabled and smack is only enabled, smack label is re-lable-ed by label_fix. To avoid, make only be labeled for selinux. --- src/udev/udev-node.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c index fa10d04..e237363 100644 --- a/src/udev/udev-node.c +++ b/src/udev/udev-node.c @@ -314,8 +314,8 @@ static int node_permissions_apply(struct udev_device *dev, bool apply, } /* set the defaults */ -if (!selinux) -label_fix(devnode, true, false); +if (!selinux use_selinux()) +label_selinux_fix(devnode, true, false); if (!smack) label_smack_path(devnode, NULL); } -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] label: rearrange security label apis
use {selinux/smack}-label.ch instread of {selinux/smack}-util.ch
move selinux label APIs to selinux-label.ch
use label_{selinxu/smack}_ prefix
---
Makefile.am | 8 +-
src/core/condition.c | 4 +-
src/core/execute.c| 2 +-
src/core/main.c | 4 +-
src/core/mount-setup.c| 2 +-
src/core/namespace.c | 4 +-
src/core/selinux-access.c | 2 +-
src/core/selinux-setup.c | 6 +-
src/core/socket.c | 26 +--
src/hostname/hostnamed.c | 2 +-
src/journal/journald-native.c | 2 +-
src/journal/journald-server.c | 2 +-
src/journal/journald-stream.c | 2 +-
src/journal/journald-syslog.c | 2 +-
src/locale/localed.c | 2 +-
src/login/logind-dbus.c | 2 +-
src/shared/dev-setup.c| 4 +-
src/shared/fileio-label.c | 12 +-
src/shared/label.c| 445 +-
src/shared/label.h| 26 +--
src/shared/mkdir-label.c | 26 +++
src/shared/mkdir.h| 2 +-
src/shared/selinux-label.c| 408 ++
src/shared/selinux-label.h| 41
src/shared/selinux-util.c | 51 -
src/shared/selinux-util.h | 27 ---
src/shared/smack-label.c | 130
src/shared/smack-label.h | 36
src/shared/smack-util.c | 89 -
src/shared/smack-util.h | 36
src/shared/socket-label.c | 6 +-
src/sysusers/sysusers.c | 2 +-
src/test/test-udev.c | 4 +-
src/timedate/timedated.c | 2 +-
src/tmpfiles/tmpfiles.c | 32 +--
src/udev/udev-node.c | 16 +-
src/udev/udevadm.c| 4 +-
src/udev/udevd.c | 4 +-
src/update-done/update-done.c | 6 +-
39 files changed, 730 insertions(+), 751 deletions(-)
create mode 100644 src/shared/selinux-label.c
create mode 100644 src/shared/selinux-label.h
delete mode 100644 src/shared/selinux-util.c
delete mode 100644 src/shared/selinux-util.h
create mode 100644 src/shared/smack-label.c
create mode 100644 src/shared/smack-label.h
delete mode 100644 src/shared/smack-util.c
delete mode 100644 src/shared/smack-util.h
diff --git a/Makefile.am b/Makefile.am
index 4028112..a2fbfd5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -821,8 +821,8 @@ libsystemd_shared_la_SOURCES = \
src/shared/boot-timestamps.c \
src/shared/mkdir.c \
src/shared/mkdir.h \
- src/shared/smack-util.c \
- src/shared/smack-util.h \
+ src/shared/smack-label.c \
+ src/shared/smack-label.h \
src/shared/apparmor-util.c \
src/shared/apparmor-util.h \
src/shared/ima-util.c \
@@ -901,8 +901,8 @@ libsystemd_label_la_SOURCES = \
src/shared/socket-label.c \
src/shared/label.c \
src/shared/label.h \
- src/shared/selinux-util.c \
- src/shared/selinux-util.h \
+ src/shared/selinux-label.c \
+ src/shared/selinux-label.h \
src/shared/mkdir-label.c \
src/shared/ask-password-api.c \
src/shared/ask-password-api.h \
diff --git a/src/core/condition.c b/src/core/condition.c
index 353e0c9..a4f671b 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -34,10 +34,10 @@
#include path-util.h
#include fileio.h
#include unit.h
-#include smack-util.h
+#include smack-label.h
#include apparmor-util.h
#include ima-util.h
-#include selinux-util.h
+#include selinux-label.h
static bool condition_test_security(Condition *c) {
assert(c);
diff --git a/src/core/execute.c b/src/core/execute.c
index d8452a6..4c63e53 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -78,7 +78,7 @@
#include fileio.h
#include unit.h
#include async.h
-#include selinux-util.h
+#include selinux-label.h
#include errno-list.h
#include af-list.h
#include mkdir.h
diff --git a/src/core/main.c b/src/core/main.c
index 792b316..5a2c00a 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1301,7 +1301,7 @@ int main(int argc, char *argv[]) {
dual_timestamp_get(security_finish_timestamp);
}
-if (label_init(NULL) 0)
+if (label_selinux_init(NULL) 0)
goto finish;
if (!skip_setup) {
@@ -1816,7 +1816,7 @@ finish:
set_free(arg_syscall_archs);
arg_syscall_archs = NULL;
-label_finish();
+label_selinux_finish();
if (reexecute) {
const char **args;
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index cc2633e..c2975b2 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -42,7 +42,7 @@
#include missing.h
#include virt.h
#include efivars.h
-#include smack-util.h
+#include smack-label.h
#include def.h
typedef enum MountMode {
diff --git a/src/core/namespace.c b/src/core/namespace.c
index fe95377..107e955 100644
--- a/src/core/namespace.c
+++
Re: [systemd-devel] start / stop daemon
Hi, [] I wonder if the people developing systemd are paying attention to a development in de Windows environment where the latest thing is that de service can report back that it is indeed still trying to stop and not just hung or not reporting back. Windows will now kill a service after a certain time when shutting down, in some cases it is killing a database that took A LONG TIME to shut down and cause the database to become inconsistent. The new development is to make sure that does not happen. If systemd is trying to become smart about stopping services it might be a good idea to have this built in. Also not just have the service report back I am still busy but also with a progress indicator which NEEDS to increase at each report so systemd can detect whether the service is indeed progressing towards a stopped state or hung in the getting there. From the past I have seen things go wrong in communication when the only thing reported back is I am busy while there was no progress being made toward the finish. Is this something the systemd team has already put on the todo list or am I the first to suggest it? Possibly: http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/21419 http://article.gmane.org/gmane.comp.sysutils.systemd.devel/21997 Introducing sd_notify() messages that can notify PID 1 about daemons reloading or shutting down, has been on the TODO list for a while Ok, it looks like the problem has been seen before. The reason I think it is a good idea to have also a progress indicator is to make sure a daemon cannot keep a system from shutting down when there is no real progress towards a stopped state. An example from my communication days. A file needs to be transported and the job is handed over to the file transfer protocol job, whichever protocol that might be in this case. The file transfer starts and after a while there are some errors on the line so some blocks are resend. Before the job is finished the line conditions become so bad that there is still some data transfer going on but each block sent has errors and needs to be resend. So the protocol job is still busy sending the file but no progress is being made. In the good old days when we were still using phone lines and modems I have seen an international filetransfer that should have lasted a few minutes keep an open line for several hours until the operator noticed the busy line when it should have been free and canceled the job. A later protocol that was developed included a progress indicator in the protocol so it could keep track whether any progress was being made towards the end, if that counter did not increase each time then a watchdog part of the protocol would kill the transfer. Something like that could happen during daemon start / stop, mainly during stop I think, where a job wants to complete some steps and tells systemd hold on, I am still busy, at the same time for whatever reason it can no longer complete those steps and at some point needs to be killed in order for the system to continue shutting down or do whatever. The hard part for the daemon will be what to use for a progress indicator and not simply use an i++ counter each time systemd asks it whether it has almost finished shutting down. You want something that indicates real progress but at the same time is small enough that is can increase each time system asks the daemon. On the other hand, that might not be too hard if systemd does not ask too often. ;-) Most daemons will not need this feature and systemd can rely on a timeout killing the job if it does not stop within x seconds. But it would be good if the start / stop protocol allows for it when a notify part is developed. After all if the system is running on the UPS batteries after a power failure and the low battery indicator was used to start a system shutdown you want the system to shutdown eventually before the battery runs out. ;-) Bonno Bloksma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
