[systemd-devel] [PATCH 1/2] label: move selinux label APIs to its util file
And add prefix selinux_ to each APIs like smack.
---
src/core/main.c | 4 +-
src/core/namespace.c | 4 +-
src/core/selinux-setup.c | 4 +-
src/core/socket.c | 12 +-
src/hostname/hostnamed.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| 419 +-
src/shared/label.h| 24 +--
src/shared/selinux-util.c | 365 +++-
src/shared/selinux-util.h | 14 ++
src/shared/smack-util.c | 45 -
src/shared/smack-util.h | 1 +
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 | 10 +-
src/udev/udevadm.c| 4 +-
src/udev/udevd.c | 4 +-
src/update-done/update-done.c | 6 +-
24 files changed, 483 insertions(+), 501 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 792b316..6f4a9da 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 (selinux_label_init(NULL) 0)
goto finish;
if (!skip_setup) {
@@ -1816,7 +1816,7 @@ finish:
set_free(arg_syscall_archs);
arg_syscall_archs = NULL;
-label_finish();
+selinux_label_finish();
if (reexecute) {
const char **args;
diff --git a/src/core/namespace.c b/src/core/namespace.c
index fe95377..d1e7cb6 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -224,9 +224,9 @@ static int mount_dev(BindMount *m) {
goto fail;
}
-label_context_set(d, st.st_mode);
+selinux_label_context_set(d, st.st_mode);
r = mknod(dn, st.st_mode, st.st_rdev);
-label_context_clear();
+selinux_label_context_clear();
if (r 0) {
r = -errno;
diff --git a/src/core/selinux-setup.c b/src/core/selinux-setup.c
index b419a27..2cd7e4c 100644
--- a/src/core/selinux-setup.c
+++ b/src/core/selinux-setup.c
@@ -87,7 +87,7 @@ int selinux_setup(bool *loaded_policy) {
retest_selinux();
/* Transition to the new context */
-r = label_get_create_label_from_exe(SYSTEMD_BINARY_PATH,
label);
+r =
selinux_label_get_create_label_from_exe(SYSTEMD_BINARY_PATH, label);
if (r 0 || label == NULL) {
log_open();
log_error(Failed to compute init label, ignoring.);
@@ -98,7 +98,7 @@ int selinux_setup(bool *loaded_policy) {
if (r 0)
log_error(Failed to transition into init
label '%s', ignoring., label);
-label_free(label);
+selinux_label_free(label);
}
after_load = now(CLOCK_MONOTONIC);
diff --git a/src/core/socket.c b/src/core/socket.c
index a16b20d..5c217cb 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -958,7 +958,7 @@ static int fifo_address_create(
mkdir_parents_label(path, directory_mode);
-r = label_context_set(path, S_IFIFO);
+r = selinux_label_context_set(path, S_IFIFO);
if (r 0)
goto fail;
@@ -981,7 +981,7 @@ static int fifo_address_create(
goto fail;
}
-label_context_clear();
+selinux_label_context_clear();
if (fstat(fd, st) 0) {
r = -errno;
@@ -1001,7 +1001,7 @@ static int fifo_address_create(
return 0;
fail:
-label_context_clear();
+selinux_label_context_clear();
safe_close(fd);
return r;
@@ -1139,7 +1139,7 @@ static int socket_open_fds(Socket *s) {
if (UNIT_ISSET(s-service)
SERVICE(UNIT_DEREF(s-service))-exec_command[SERVICE_EXEC_START]) {
-r =
label_get_create_label_from_exe(SERVICE(UNIT_DEREF(s-service))-exec_command[SERVICE_EXEC_START]-path,
label);
+r =
selinux_label_get_create_label_from_exe(SERVICE(UNIT_DEREF(s-service))-exec_command[SERVICE_EXEC_START]-path,
label);
if (r 0 r != -EPERM)
return r;
}
@@ -1200,12 +1200,12 @@ static int socket_open_fds(Socket *s) {
[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 9ec98bc..f4f4827 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()) +selinux_label_fix(devnode, true, false); if (!smack) smack_label_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] Link down for systemd articles
Hi, I have been working on systemd recently and was referring to articles by Lennart Poettering for the same. However, I am not able to access the articles hosted at the below link - http://0pointer.de/blog/projects/ Is the server down or something ? If anyone else is facing the same issues, kindly let me know. P.S- I am sorry if I am posting to the wrong list, but I do not know where else to ask for help. Regards, Saket Sinha ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Link down for systemd articles
This server is Lennarts Blog and other server and yes it seems to be down... Lennart is probably fixing it soonish. Meanwhile there is still google cache: http://webcache.googleusercontent.com/search?q=cache:i83NF0kf5wkJ:0pointer.de/blog/projects+cd=1hl=enct=clnkgl=declient=firefox-a On Mo, Aug 18, 2014 at 9:15 , Saket Sinha saket.sinh...@gmail.com wrote: Hi, I have been working on systemd recently and was referring to articles by Lennart Poettering for the same. However, I am not able to access the articles hosted at the below link - http://0pointer.de/blog/projects/ Is the server down or something ? If anyone else is facing the same issues, kindly let me know. P.S- I am sorry if I am posting to the wrong list, but I do not know where else to ask for help. Regards, Saket Sinha ___ 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] Link down for systemd articles
Thanks Dietrich. That was helpful. Regards, Saket Sinha On Mon, Aug 18, 2014 at 12:52 PM, Dietrich enau...@googlemail.com wrote: This server is Lennarts Blog and other server and yes it seems to be down... Lennart is probably fixing it soonish. Meanwhile there is still google cache: http://webcache.googleusercontent.com/search?q=cache:i83NF0kf5wkJ:0pointer.de/blog/projects+cd=1hl=enct=clnkgl=declient=firefox-a On Mo, Aug 18, 2014 at 9:15 , Saket Sinha saket.sinh...@gmail.com wrote: Hi, I have been working on systemd recently and was referring to articles by Lennart Poettering for the same. However, I am not able to access the articles hosted at the below link - http://0pointer.de/blog/projects/ Is the server down or something ? If anyone else is facing the same issues, kindly let me know. P.S- I am sorry if I am posting to the wrong list, but I do not know where else to ask for help. Regards, Saket Sinha ___ 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] Networkd fails to activate the device on boot
On Sat, Aug 16, 2014 at 6:53 PM, Thomas Bächler tho...@archlinux.org wrote: Hello Tom, I am using systemd 215-4 from Arch Linux. I have the following configuration files in /etc/systemd/network: # 01-lan.network [Match] Name=enp3s0 [Network] Address=10.23.42.4/26 Gateway=10.23.42.3 # 01-qemu.netdev [NetDev] MACAddress=1a:de:ad:be:ef:01 Name=qemu Kind=tap # 01-qemu.network [Match] Name=qemu [Network] Address=10.23.42.129/26 I have two problems with this setup: 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) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. Here is an excerpt from the journal: [2.356909] lije systemd[1]: Starting Network Service... [2.377715] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377862] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377960] lije systemd-networkd[367]: qemu: link configured [2.379489] lije systemd[1]: Started Network Service. [ 57.298036] lije systemd[1]: Stopping Network Service... [ 57.298776] lije systemd-networkd[367]: Received SIGTERM from PID 1 (systemd). [ 57.364169] lije systemd[1]: Starting Network Service... [ 57.451984] lije systemd-networkd[490]: lo : gained carrier [ 57.452133] lije systemd[1]: Started Network Service. [ 57.492641] lije systemd-networkd[490]: qemu: link configured [ 57.492732] lije systemd-networkd[490]: enp3s0 : link configured [ 59.074472] lije systemd-networkd[490]: enp3s0 : gained carrier Any ideas? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Make journalctl start at the end of the journal by default
Hi,
Having to often use journalctl it has slowly driven me insane with the
default options not matching common use cases.
Attached is already a patch to start the journal at the end. Usually
people check the logs when something went wrong, and don't care about
what happened three weeks ago at the beginning of the log. Yes you can
press the end key to skip to the end but in some cases that freezes up
the console for over a minute.
Other gripes are --no-pager... way too long to type on a virtual
keyboard when you are trying to use the logs old style with common unix
utilities. Maybe not having it by default, or introducing a shorter
command switch should not be hard to add.
And also I would like to see the full logs always by default. Usually
after lots of searching you find the offending log entry for the error,
only to find out you forgot to pass the right command line options to
journalctl and the important bit is cut off.
If you guys are willing to also consider those other two gripes I will
glady submit patches for those also.
Regards,
Philippe
From b4c8bd945bc987edd64702e781daea2caff8eeab Mon Sep 17 00:00:00 2001
From: Philippe De Swert philippe.desw...@jollamobile.com
Date: Mon, 18 Aug 2014 14:39:19 +0300
Subject: [PATCH] journalctl : automatically go to the end of the log
Usually we do not care about the beginning of the log, as we want to look
at it when something went wrong. So usually this would be the end. So changing
the end feature into a start feature will cause less typing. (Also jumping to
the end of a log with the end key sometimes takes a considerable amount of time,
so we avoid that issue here too). To restore the old behaviour to start at the
beginning of the log, there is now -s or --pager-start. -e is kept for backwards
compatability.
Signed-off-by: Philippe De Swert philippe.desw...@jollamobile.com
---
src/journal/journalctl.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 5c4a71d..67f3a26 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -63,7 +63,7 @@
#define DEFAULT_FSS_INTERVAL_USEC (15*USEC_PER_MINUTE)
static OutputMode arg_output = OUTPUT_SHORT;
-static bool arg_pager_end = false;
+static bool arg_pager_end = true;
static bool arg_follow = false;
static bool arg_full = true;
static bool arg_all = false;
@@ -182,6 +182,7 @@ static void help(void) {
--user-unit=UNIT Show data only from the specified user session unit\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
+ -s --pager-start Start at the beginning of the journal in the pager\n
-f --follow Follow the journal\n
-n --lines[=INTEGER] Number of journal entries to show\n
--no-tail Show all lines, even in follow mode\n
@@ -255,6 +256,7 @@ static int parse_argv(int argc, char *argv[]) {
{ version , no_argument, NULL, ARG_VERSION},
{ no-pager, no_argument, NULL, ARG_NO_PAGER },
{ pager-end, no_argument, NULL, 'e'},
+{ pager-start,no_argument, NULL, 's'},
{ follow, no_argument, NULL, 'f'},
{ force, no_argument, NULL, ARG_FORCE },
{ output, required_argument, NULL, 'o'},
@@ -304,7 +306,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, hesfo:aln::qmb::kD:p:c:u:F:xrM:, options, NULL)) = 0)
switch (c) {
@@ -329,6 +331,15 @@ static int parse_argv(int argc, char *argv[]) {
break;
+case 's':
+arg_pager_end = false;
+
+if (arg_lines 0)
+arg_lines = 1000;
+
+break;
+
+
case 'f':
arg_follow = true;
break;
--
1.8.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make journalctl start at the end of the journal by default
2014-08-18 13:46 GMT+02:00 Philippe De Swert philippedesw...@gmail.com: Hi, Hi, Having to often use journalctl it has slowly driven me insane with the default options not matching common use cases. Attached is already a patch to start the journal at the end. Usually people check the logs when something went wrong, and don't care about what happened three weeks ago at the beginning of the log. Yes you can press the end key to skip to the end but in some cases that freezes up the console for over a minute. There is the --reverse or -r option to show the newest entries first, is this what you are looking for ? Other gripes are --no-pager... way too long to type on a virtual keyboard when you are trying to use the logs old style with common unix utilities. Maybe not having it by default, or introducing a shorter command switch should not be hard to add. And also I would like to see the full logs always by default. Usually after lots of searching you find the offending log entry for the error, only to find out you forgot to pass the right command line options to journalctl and the important bit is cut off. There is the --all or -a option for this. In the end, you just have to use journalctl -ar If you guys are willing to also consider those other two gripes I will glady submit patches for those also. Regards, Philippe ___ 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] compile with clang broken
On Sat, 16.08.14 13:29, Daniele Nicolodi (dani...@grinta.net) wrote:
On 16/08/2014 12:35, David Herrmann wrote:
On Fri, Aug 15, 2014 at 5:22 PM, Daniele Nicolodi dani...@grinta.net
wrote:
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:
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.
Indeed it does add padding. Adding the __packed__ attribute solves the
problem:
#define MAXSIZE(A, B) sizeof( \
union __attribute__((__packed__)) { \
__typeof(A) a; __typeof(B) b;})
I like this actually. I am also fine with CONST_MAX(). I'd also be fine
with having both... ;-)
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] [RFC] Integrate export mount command in code
On Mon, 18.08.14 00:25, Timofey Titovets (nefelim...@gmail.com) wrote: Good time of day, i just want to ask: Systemd depend on util-linux mount command and in code we call him, may have a sense to import and cleanup code to systemd base, and just call function in systemd, instead of using mount command? But only benefit what i see: it faster, when call external command, but i can miss something No. I don't think this would be a good idea. First of all, util-linux is maintained very well upstream (by Karel Zak, who's actually on the same team at RH as Kay and I are). Then, the current mount binary is actually a real API, with it callouts to /usr/sbin/mount.fstype and suchlike, we cannot get rid of that. This is frequently used for network file systems (such as NFS), or FUSE. Then, it wouldn't actually get us anything, since we have to invoke the mount() syscall out-of-process anyway (since it is blocking). But if we invoke it out-of-process, we have to have an exec() transition in the child, because otherwise just forking things would simply result in tons of pagefaults in the parent (due to the copy-of-write semantics of fork()), and we don't want that for perfomance reasons. So, I really don't see any benefit in merging that. 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] bus-control: Fix cgroup handling
On Sat, 16.08.14 13:55, Denis Kenzior (denk...@gmail.com) wrote: On systems without properly setup systemd, cg_get_root_path returns -ENOENT. This means that busctl doesn't display much information. busctl monitor also fails whenever it intercepts messages. This fix fakes creates a fake / root cgroup which lets busctl work on such systems. Sounds generally OK, but now that this is logic is more thant just one if check plus a function call, and given that we need this twice, could we move this to its own utility function in sd-bus or so? Create a new bus_get_root_path() or so, which fills in the cgroup_root if it is missing, and do nothing if we already know it? Also, there's an OOM check missing after the strdup(). 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] suspend-utils and systemd
On Sat, 16.08.14 13:48, Rodolfo García Peñas (kix) (k...@debian.org) wrote: Heya, Hi, I am new on the list. Thanks for your work with systemd. I am trying to run systemd and suspend-utils (uswsusp in Debian) and I don't know how to do it. I was checking how to include support for suspend with normal packages (server daemons,...) but I am not sure how to implement it with suspend-utils. Reading [1], it modify the systemd hibernate/supsend/hybrid scripts, but IMO this is not the right option to include support in suspend-utils and uswsusp package. We only support the in-kernel default suspend-to-disk and suspend-to-ram implementations. We don't really support any other implementations of the logic upstream, and especially not out-of-tree ones. You can of course override the implementation of systemd-suspend.service and system-hibernate.service, to whatever you like. However, I really wonder, what's wrong with the normal in-kernel implementations? Why use something 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] Make journalctl start at the end of the journal by default
Hi,
Seems the patch has been scrubbed. Will re-send it later if there is interest
to have it. Should have used git send-email I guess, but now badly inlined at
the bottom of this email.
Thank you for your help, but you seem to have misunderstood what I am after.
On 18/08/14 15:08, Ronny Chevalier wrote:
2014-08-18 13:46 GMT+02:00 Philippe De Swert philippedesw...@gmail.com:
Having to often use journalctl it has slowly driven me insane with the
default options not matching common use cases.
Attached is already a patch to start the journal at the end. Usually people
check the logs when something went wrong, and don't care about what happened
three weeks ago at the beginning of the log. Yes you can press the end key
to skip to the end but in some cases that freezes up the console for over a
minute.
There is the --reverse or -r option to show the newest entries first,
is this what you are looking for ?
No. I want -e as default option, as that is what makes sense to me. And I keep
hearing the same from lots of people that -e should be default.
Other gripes are --no-pager... way too long to type on a virtual keyboard
when you are trying to use the logs old style with common unix
utilities. Maybe not having it by default, or introducing a shorter command
switch should not be hard to add.
And also I would like to see the full logs always by default. Usually after
lots of searching you find the offending log entry for the error, only to
find out you forgot to pass the right command line options to journalctl and
the important bit is cut off.
There is the --all or -a option for this.
In the end, you just have to use journalctl -ar
The point is that I think that -a should be default. I can't think of any
reason
to have truncated and mangled logs by default. As it too often happens that you
forget to add the flag as I just explained, you end up to have do all the
searching again due to the interesting bit of the log being cut/truncated.
The issue is having to use all those switches. Mainly I get sick of having to
type
journalctl --no-pager -a -e on a virtual keyboard every time on a development
platform that gets reflashed continuously so having aliases etc is not really a
workable option. And well and the pager I do sometimes want it and other times
I
don't. Depends on what I want to do.
As I stated I am willing to send patches to fix journalctl default behaviour to
match
common use cases. I know about the switches. My point is that you should not
need to
remember every time to use some switches to get default usable behaviour from
journalctl
when performing a simple basic operation.
Regards,
Philippe
From b4c8bd945bc987edd64702e781daea2caff8eeab Mon Sep 17 00:00:00 2001
From: Philippe De Swert philippedesw...@gmail.com
Date: Mon, 18 Aug 2014 14:39:19 +0300
Subject: [PATCH] journalctl : automatically go to the end of the log
Usually we do not care about the beginning of the log, as we want to look
at it when something went wrong. So usually this would be the end. So changing
the end feature into a start feature will cause less typing. (Also jumping to
the end of a log with the end key sometimes takes a considerable amount of time,
so we avoid that issue here too). To restore the old behaviour to start at the
beginning of the log, there is now -s or --pager-start. -e is kept for backwards
compatibility.
Signed-off-by: Philippe De Swert philippedesw...@gmail.com
---
src/journal/journalctl.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 5c4a71d..67f3a26 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -63,7 +63,7 @@
#define DEFAULT_FSS_INTERVAL_USEC (15*USEC_PER_MINUTE)
static OutputMode arg_output = OUTPUT_SHORT;
-static bool arg_pager_end = false;
+static bool arg_pager_end = true;
static bool arg_follow = false;
static bool arg_full = true;
static bool arg_all = false;
@@ -182,6 +182,7 @@ static void help(void) {
--user-unit=UNIT Show data only from the specified
user session unit\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
+ -s --pager-start Start at the beginning of the
journal in the pager\n
-f --follow Follow the journal\n
-n --lines[=INTEGER] Number of journal entries to show\n
--no-tail Show all lines, even in follow
mode\n
@@ -255,6 +256,7 @@ static int parse_argv(int argc, char *argv[]) {
{ version , no_argument, NULL, ARG_VERSION
},
{ no-pager, no_argument, NULL, ARG_NO_PAGER
},
{ pager-end, no_argument, NULL, 'e'
},
+
Re: [systemd-devel] [PATCH 1/2] label: move selinux label APIs to its util file
On Mon, 18.08.14 15:06, WaLyong Cho (walyong@samsung.com) wrote: And add prefix selinux_ to each APIs like smack. I am a bit concerned about this, as selinux_ is really the prefix the selinux libraries use for most of their newer symbols. And they have a lot of symbols that actually are named very similar to ours (given that ours are just wrappers for them anyway to just make their apis more digestable...). libselinux is quite chaotic, they also use the selabel_ prefix sometimes, and sometimes no prefix it all. Other times they use the security_ prefix. Seems they really didn't understand the concept of namespacing in C... Anyway, maybe we can find a different prefix to use. selnx_ or so? Not pretty, but at least distinct? sel_? se_linux_? util_selinux? or maybe we just call call our internal selinux apis label_selinux_xyz, and our smack apis label_smack_xyz? Or maybe mac_selinux_xyz and mac_smack_xyz? I think the latter sounds most appropriate to me right now, as it is still somewhat short, and sufficiently distinctive. I'd probably go for that. Any other suggestions? 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] PGP replacement?
On Sun, 17.08.14 08:35, Mauricio Tavares (raubvo...@gmail.com) wrote: So http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html makes the point that pgp is old school and should be taken to the pasture to die. Like upstart and inetd I take. Is there a replacement built into systemd? If not, I would like to suggest that as something to be integrated into it that would learn from the mistakes of pgp. systemd is supposed to be an implementation of the plumbing layer of an operating system. PGP is a crypt spec plus one implementation of it. It's very different things, and I pretty sure a PGP reinvention has no place in systemd. Sorry, 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] PGP replacement?
On Sun, 17.08.14 15:13, Mauricio Tavares (raubvo...@gmail.com) wrote: post seem to be obvious trolling. Please do not do that. I was thinking on secure event reporting, maybe with firewalld or even earlier. I was not aware that is obviously trolling, so I do apologize and will say no more on the subject. firewalld is not a systemd project. And we really don't want to be associated with it. 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] seat1 ACL
On Sun, 17.08.14 20:17, Floris (jkflo...@dds.nl) wrote: Hey, maybe I'm missing something, but a user on the second seat (seat1) does not get the right rights from logind. What version of systemd is this? Please only report bugs upstream that are about somewhat recent systemd versions. A user logs in on seat1, but the user:Debian-gdm line is removed, instead of changed. $ getfacl /dev/snd/controlC2 # file: dev/snd/controlC2 # owner: root # group: audio user::rw- group::rw- mask::rw- other::--- On seat0 I get the expected user:floris:rw- line $ getfacl /dev/snd/controlC3 # file: dev/snd/controlC3 # owner: root # group: audio user::rw- user:floris:rw- group::rw- mask::rw- other::--- Do I miss a package or is this a bug? Hmm, does loginctl show the new session as properly assigned to your new seat, and active and everything? 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] Link down for systemd articles
On Mon, 18.08.14 12:45, Saket Sinha (saket.sinh...@gmail.com) wrote: Hi, I have been working on systemd recently and was referring to articles by Lennart Poettering for the same. However, I am not able to access the articles hosted at the below link - http://0pointer.de/blog/projects/ Is the server down or something ? Somebody found it funny to DoS my server with HTTP or so. I turned HTTP off temporarily. I have now started it again. 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] Make journalctl start at the end of the journal by default
On Mon, 18.08.14 14:46, Philippe De Swert (philippedesw...@gmail.com) wrote: Hi, Having to often use journalctl it has slowly driven me insane with the default options not matching common use cases. Attached is already a patch to start the journal at the end. Usually people check the logs when something went wrong, and don't care about what happened three weeks ago at the beginning of the log. Yes you can press the end key to skip to the end but in some cases that freezes up the console for over a minute. Well, its more complex than that. I know that a lot of people do journalctl -b more often than journalctl -e. I really don#t want to be in the business of saying that -e is the way to go and -b is not. I am pretty sure we should choose defaults that are obvious, and I figure showing all the logs is the most obvious thing to do, if you don't specify anything. Moreover, journalctl is frequently now used in scripts, we cannot change the defaults really now, that would break all scripts. journalctl is API now. I'd recommend to simple set a shell alias to map journalctl to journalctl -e if that's what you prefer. That way you maintain API compatibility while simplifying what you have to type the way you prefer. (Actually, you could even map j to journalctl -e, making things even easier to type). Other gripes are --no-pager... way too long to type on a virtual keyboard when you are trying to use the logs old style with common unix utilities. Maybe not having it by default, or introducing a shorter command switch should not be hard to add. Hmm? Note that the pager is turned off automatzically if you use journalctl in a pipe. --no-pager is nothing you ever should need to type manually... And also I would like to see the full logs always by default. Usually after lots of searching you find the offending log entry for the error, only to find out you forgot to pass the right command line options to journalctl and the important bit is cut off. cut off? You can just scroll to the right in most pagers, such as less? 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] Make journalctl start at the end of the journal by default
On Mon, 18.08.14 16:02, Philippe De Swert (philippedesw...@gmail.com) wrote: The point is that I think that -a should be default. I can't think of any reason to have truncated and mangled logs by default. As it too often happens that you forget to add the flag as I just explained, you end up to have do all the searching again due to the interesting bit of the log being cut/truncated. SInce a longer time lines are not truncated anymore, unless your pager does it. But less doesn't, you can just scroll to the right... And if you disable the pager, we won't either... 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 2/2] tmpfiles: explicitly check for existing files
On Sun, 17.08.14 09:45, Michael Olbrich (m.olbr...@pengutronix.de) wrote: On read-only filesystems trying to create the target will not fail with EEXIST but with EROFS. Hmm, what precisely fails with EROFS? if there's an existing directory on some read-only fs, and we issue mkdir() on it, then this will fail with EROFS you say? if that's the case, then I#d really prefer if we could fix this by checkinf if an mkdir() fails whether the destination already existed anyway and then just continueing. i.e. mkdir() first, and if it fails, then stat() it instead, and see if it already is a dir. And if so, continue. 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 1/2] label: move selinux label APIs to its util file
On 08/18/2014 10:09 PM, Lennart Poettering wrote:
On Mon, 18.08.14 15:06, WaLyong Cho (walyong@samsung.com) wrote:
And add prefix selinux_ to each APIs like smack.
I am a bit concerned about this, as selinux_ is really the prefix the
selinux libraries use for most of their newer symbols. And they have a
lot of symbols that actually are named very similar to ours (given that
ours are just wrappers for them anyway to just make their apis more
digestable...). libselinux is quite chaotic, they also use the
selabel_ prefix sometimes, and sometimes no prefix it all. Other times
they use the security_ prefix. Seems they really didn't understand the
concept of namespacing in C...
Anyway, maybe we can find a different prefix to use. selnx_ or so? Not
pretty, but at least distinct? sel_? se_linux_? util_selinux?
or maybe we just call call our internal selinux apis
label_selinux_xyz, and our smack apis label_smack_xyz?
Or maybe mac_selinux_xyz and mac_smack_xyz?
I think the latter sounds most appropriate to me right now, as it is
still somewhat short, and sufficiently distinctive. I'd probably go for
that. Any other suggestions?
Both sounds good.
How does we do on filename?
label-selinux.{c/h} and label-smack.{c/h}?
Or
mac.{c/h}, mac-selinux.{c/h} and mac-smack.{c/h}?
And does we consider also selinux-{access/setup}.{c/h} and
smack-setup.{c/h}?
Lennart
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Build errors with lto and compat-libs
On Sun, 17.08.14 09:54, Michael Olbrich (m.olbr...@pengutronix.de) wrote: Hi, With --enable-compat-libs building fails like this: CCLD libsystemd-journal.la [...] /tmp/ccISOiYU.ltrans1.ltrans.o: In function `sd_journal_process': ccISOiYU.ltrans1.o:(.text+0x0): multiple definition of `sd_journal_process' libsystemd_journal_internal_la-sd-journal.o (symbol from plugin):(.text+0x0): first defined here [...] for all symbols listed in src/compat-libs/libsystemd-journal.sym I have no idea what happens here, but making 'obsolete_lib()' a noop or removing lto from configure.ac 'fixes' the problem. This is with gcc-4.8.2 and binutils-2.24 building for ARM. Any ideas what happens here? No really. But I figure LTO is not very reliable on ARM and stuff. It's probably best to turn it off there. 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] bootchart: use NSEC_PER_SEC
On Sat, 16.08.14 14:24, 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..d838a53 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 / NSEC_PER_SEC));
}
This is really not the same. You need to cast NSEC_PER_SEC into a double
before making use of it. Note that the value you specified was a double
because it was suffixed with .0, but your replacement is a usec_t.
This should work:
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 / NSEC_PER_SEC));
Same here:
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] util: do not execute files without exec permission
On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
What's the rationale here? I think it makes a lot of sense to output an
error if people drop non-executable files in such a directory...
---
src/shared/util.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 18d40f3..3a03470 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3921,6 +3921,10 @@ void execute_directory(const char *directory, DIR *d,
usec_t timeout, char *argv
_exit(EXIT_FAILURE);
}
+if (access(path, X_OK) 0) {
+continue;
+}
+
pid = fork();
if (pid 0) {
log_error(Failed to fork: %m);
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] Implementing resume from hibernation as a systemd unit file
On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). 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] Implementing resume from hibernation as a systemd unit file
On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
On Fri, 15.08.14 14:16, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Daniel, To facility the feature of doing an asynchronous sending of messages when the bus is idle, make sure to return POLLOUT | POLLWRNORM from kdbus_handle_poll. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/handle.c b/handle.c index ac6868133280..fc15d28351b3 100644 --- a/handle.c +++ b/handle.c @@ -884,6 +884,8 @@ static unsigned int kdbus_handle_poll(struct file *file, mask |= POLLERR | POLLHUP; else if (!list_empty(conn-msg_list)) mask |= POLLIN | POLLRDNORM; + else + mask |= POLLOUT | POLLWRNORM; Hmm, what's your use case here? list_empty(conn-msg_list) only checks the incoming list of the current connection for pending messages. That doesn't tell you whether the bus is idle, or if your receiving end has messages pending ... if you are a good client citizen, then you only send messages when POLLOUT gets signaled. That is what this is allowing now. Blindly sending messages is never a good idea. You want to poll for POLLOUT first. This does not make a big difference for current kernel, but it allows future extensions when the clients are well behaving and just waiting for POLLOUT. Meaning once the kernel does not signal POLLOUT, no new messages will come from the client. Current code does not do this POLLOUT before sending a messages, but our kdbus client actually does that. It is the right thing to do. And we have been doing this with all of our protocols that are using asynchronous IO. No point in kdbus being any different. Well, kdbus keeps per-reciever buffers only, hence signalling on the kdbus fd when you are able to write is not really possible, since this information is not bound to the sender fd but only to the receiever of which there are many... If I understand you correctly you hence want the kdbus fd to always return EPOLLOUT then, because if a client wants to send something it can do that at any time? If that's the case then POLLOUT should really be ORed into the mask unconditionally, not just in some cases... So, I can sympathize with what you are trying to do. However, I think your patch doesn't do the right thing... It should really OR the POLLOUT into all masks always. 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] core: collapse JOB_RELOAD on an inactive unit into JOB_NOP
On Fri, 15.08.14 21:10, Michael Biebl (mbi...@gmail.com) wrote: 2014-08-15 12:50 GMT+02:00 Lennart Poettering lenn...@poettering.net: I think most of the confusion here comes from the fact that sysv service restarts don't care about ordering at all, really, and we do. But the answer to that is not to weaken the current strong semantics of blocking, but simply not to request blocking operation at all, i.e. use --no-block, and just queue things in, instead of waiting for them. Note that on FEdora the sysv /sbin/service glue actually adds in --no-block for many cases, too, due to the stricter requirements of systemd there. I just had a look at /sbin/service and/etc/init.d/functions as shipped by F20 and couldn't find any traces of --no-block. I'd be interested to know under what conditions you add --no-block. Ah, sorry, it doesn't use --no-block. But it does use the ignore-dependencies stuff, look for SYSTEMCTL_IGNORE_DEPENDENCIES in /etc/rc.d/init.d/functions. 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] seat1 ACL
Op Mon, 18 Aug 2014 15:14:31 +0200 schreef Lennart Poettering lenn...@poettering.net: On Sun, 17.08.14 20:17, Floris (jkflo...@dds.nl) wrote: Hey, maybe I'm missing something, but a user on the second seat (seat1) does not get the right rights from logind. What version of systemd is this? Please only report bugs upstream that are about somewhat recent systemd versions. systemd 208 (Yes, Debian is often a couple of versions behind) Do I miss a package or is this a bug? Hmm, does loginctl show the new session as properly assigned to your new seat, and active and everything? Thanks for pointing me to look into the right place. $ loginctl show-session 3 Id=3 Timestamp=ma 2014-08-18 15:42:35 CEST TimestampMonotonic=175185511 VTNr=0 Display=:1 Remote=no Service=gdm-password Scope=session-3.scope Leader=1722 Audit=3 Type=x11 Class=user Active=no State=online IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 Name=test $ loginctl activate 3 $ loginctl show-session 3 ... Audit=3 Type=x11 Class=user Active=no State=online IdleHint=no ... and everything is working as expected. strange why I have to set it manually. Maybe some clues where to look? thanks, floris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] seat1 ACL
On Mon, 18.08.14 16:05, Floris (jkflo...@dds.nl) wrote: Op Mon, 18 Aug 2014 15:14:31 +0200 schreef Lennart Poettering lenn...@poettering.net: On Sun, 17.08.14 20:17, Floris (jkflo...@dds.nl) wrote: Hey, maybe I'm missing something, but a user on the second seat (seat1) does not get the right rights from logind. What version of systemd is this? Please only report bugs upstream that are about somewhat recent systemd versions. systemd 208 (Yes, Debian is often a couple of versions behind) Oh yuck. Please try a newer systemd and logind and newer gdm first. 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 kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
Hi Lennart, To facility the feature of doing an asynchronous sending of messages when the bus is idle, make sure to return POLLOUT | POLLWRNORM from kdbus_handle_poll. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/handle.c b/handle.c index ac6868133280..fc15d28351b3 100644 --- a/handle.c +++ b/handle.c @@ -884,6 +884,8 @@ static unsigned int kdbus_handle_poll(struct file *file, mask |= POLLERR | POLLHUP; else if (!list_empty(conn-msg_list)) mask |= POLLIN | POLLRDNORM; + else + mask |= POLLOUT | POLLWRNORM; Hmm, what's your use case here? list_empty(conn-msg_list) only checks the incoming list of the current connection for pending messages. That doesn't tell you whether the bus is idle, or if your receiving end has messages pending ... if you are a good client citizen, then you only send messages when POLLOUT gets signaled. That is what this is allowing now. Blindly sending messages is never a good idea. You want to poll for POLLOUT first. This does not make a big difference for current kernel, but it allows future extensions when the clients are well behaving and just waiting for POLLOUT. Meaning once the kernel does not signal POLLOUT, no new messages will come from the client. Current code does not do this POLLOUT before sending a messages, but our kdbus client actually does that. It is the right thing to do. And we have been doing this with all of our protocols that are using asynchronous IO. No point in kdbus being any different. Well, kdbus keeps per-reciever buffers only, hence signalling on the kdbus fd when you are able to write is not really possible, since this information is not bound to the sender fd but only to the receiever of which there are many... If I understand you correctly you hence want the kdbus fd to always return EPOLLOUT then, because if a client wants to send something it can do that at any time? If that's the case then POLLOUT should really be ORed into the mask unconditionally, not just in some cases... So, I can sympathize with what you are trying to do. However, I think your patch doesn't do the right thing... It should really OR the POLLOUT into all masks always. always returning POLLOUT is also fine. As long as the fd signals POLLOUT and not just swallows it. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make journalctl start at the end of the journal by default
Hi, Thanks for answering. On 18/08/14 16:27, Lennart Poettering wrote: On Mon, 18.08.14 14:46, Philippe De Swert (philippedesw...@gmail.com) wrote: Well, its more complex than that. I know that a lot of people do journalctl -b more often than journalctl -e. I really don#t want to be in the business of saying that -e is the way to go and -b is not. I am pretty sure we should choose defaults that are obvious, and I figure showing all the logs is the most obvious thing to do, if you don't specify anything. Moreover, journalctl is frequently now used in scripts, we cannot change the defaults really now, that would break all scripts. journalctl is API now. I could argue that most people who use -b might not know about -e, or that scripts would not use default journalctl behaviour. (I actually included a -s option in the patch to have journalctl with the old behaviour) But this will only degrade in a personal preferences game I guess. I'd recommend to simple set a shell alias to map journalctl to journalctl -e if that's what you prefer. That way you maintain API compatibility while simplifying what you have to type the way you prefer. (Actually, you could even map j to journalctl -e, making things even easier to type). I did explain I knew what aliases were and why they would not work. Constantly changing environment, needing to make sure something does not magically work on one device due to aliases and not on another etc... Other gripes are --no-pager... way too long to type on a virtual keyboard when you are trying to use the logs old style with common unix utilities. Maybe not having it by default, or introducing a shorter command switch should not be hard to add. Hmm? Note that the pager is turned off automatzically if you use journalctl in a pipe. --no-pager is nothing you ever should need to type manually... Had not noticed that. Got used to hurt my fingers and typing --no-pager the whole time. Good to know, thanks. And also I would like to see the full logs always by default. Usually after lots of searching you find the offending log entry for the error, only to find out you forgot to pass the right command line options to journalctl and the important bit is cut off. cut off? You can just scroll to the right in most pagers, such as less? Good luck doing that when you don't have arrow keys available. Moreover I still believe wrapping would be more useful. But personal preferences again I guess. So I guess I will just maintain the patches for our internal use then, if we chose to do so at the cost of diverging from upstream. At least the people here like the behaviour I proposed. If anybody else wants the patches I will gladly provide them. Regards, Philippe ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make journalctl start at the end of the journal by default
On Mon, 18.08.14 17:19, Philippe De Swert (philippedesw...@gmail.com) wrote: Moreover, journalctl is frequently now used in scripts, we cannot change the defaults really now, that would break all scripts. journalctl is API now. I could argue that most people who use -b might not know about -e, or that scripts would not use default journalctl behaviour. (I actually included a -s option in the patch to have journalctl with the old behaviour) But this will only degrade in a personal preferences game I guess. I'd recommend to simple set a shell alias to map journalctl to journalctl -e if that's what you prefer. That way you maintain API compatibility while simplifying what you have to type the way you prefer. (Actually, you could even map j to journalctl -e, making things even easier to type). I did explain I knew what aliases were and why they would not work. Constantly changing environment, needing to make sure something does not magically work on one device due to aliases and not on another etc... I think it might make sense to maybe file bugs against a number of distros, asking them to maybe set the alias by default, the way many distros set shorter aliases by default for some ls invocations. We could maybe even ship something like that in systemd upstream, but afaik there's no standard place we could hook that into bash. alias jb='journalctl -b' alias je='journalctl -e' Doesn't sound too terrible for me to have as suggested default aliases... And also I would like to see the full logs always by default. Usually after lots of searching you find the offending log entry for the error, only to find out you forgot to pass the right command line options to journalctl and the important bit is cut off. cut off? You can just scroll to the right in most pagers, such as less? Good luck doing that when you don't have arrow keys available. Moreover I still believe wrapping would be more useful. But personal preferences again I guess. I am pretty sure doing the auto-paging thing (the same way as git, and others do it) improves end-user experience for most people. I mean, I think having arrow keys is the common case. Not having them is the rare exception... 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] Make journalctl start at the end of the journal by default
On Mon, Aug 18, 2014 at 04:42:52PM +0200, Lennart Poettering wrote: On Mon, 18.08.14 17:19, Philippe De Swert (philippedesw...@gmail.com) wrote: Moreover, journalctl is frequently now used in scripts, we cannot change the defaults really now, that would break all scripts. journalctl is API now. I could argue that most people who use -b might not know about -e, or that scripts would not use default journalctl behaviour. (I actually included a -s option in the patch to have journalctl with the old behaviour) But this will only degrade in a personal preferences game I guess. I'd recommend to simple set a shell alias to map journalctl to journalctl -e if that's what you prefer. That way you maintain API compatibility while simplifying what you have to type the way you prefer. (Actually, you could even map j to journalctl -e, making things even easier to type). I did explain I knew what aliases were and why they would not work. Constantly changing environment, needing to make sure something does not magically work on one device due to aliases and not on another etc... I think it might make sense to maybe file bugs against a number of distros, asking them to maybe set the alias by default, the way many distros set shorter aliases by default for some ls invocations. We could maybe even ship something like that in systemd upstream, but afaik there's no standard place we could hook that into bash. alias jb='journalctl -b' alias je='journalctl -e' Doesn't sound too terrible for me to have as suggested default aliases... Many shells use 'j' for and similar things for jobs, autojump uses 'j' to change directories... I don't think we should try to enter into the crowded world of short shell aliases. Also, it seems that there aren't any other commands starting with 'jou', so 'jouTAB' should be enough. And also I would like to see the full logs always by default. Usually after lots of searching you find the offending log entry for the error, only to find out you forgot to pass the right command line options to journalctl and the important bit is cut off. cut off? You can just scroll to the right in most pagers, such as less? Good luck doing that when you don't have arrow keys available. Moreover I still believe wrapping would be more useful. But personal preferences again I guess. I am pretty sure doing the auto-paging thing (the same way as git, and others do it) improves end-user experience for most people. I mean, I think having arrow keys is the common case. Not having them is the rare exception... You can say -Senter in less to instruct it to wrap lines. For me, the only conclusion from this thread is that we should expand the EXAMPLES chapter in journalctl(1) to deal more with pipes and common usage. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
Hi On Mon, Aug 18, 2014 at 4:15 PM, Marcel Holtmann mar...@holtmann.org wrote: Hi Lennart, To facility the feature of doing an asynchronous sending of messages when the bus is idle, make sure to return POLLOUT | POLLWRNORM from kdbus_handle_poll. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- handle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/handle.c b/handle.c index ac6868133280..fc15d28351b3 100644 --- a/handle.c +++ b/handle.c @@ -884,6 +884,8 @@ static unsigned int kdbus_handle_poll(struct file *file, mask |= POLLERR | POLLHUP; else if (!list_empty(conn-msg_list)) mask |= POLLIN | POLLRDNORM; + else + mask |= POLLOUT | POLLWRNORM; Hmm, what's your use case here? list_empty(conn-msg_list) only checks the incoming list of the current connection for pending messages. That doesn't tell you whether the bus is idle, or if your receiving end has messages pending ... if you are a good client citizen, then you only send messages when POLLOUT gets signaled. That is what this is allowing now. Blindly sending messages is never a good idea. You want to poll for POLLOUT first. This does not make a big difference for current kernel, but it allows future extensions when the clients are well behaving and just waiting for POLLOUT. Meaning once the kernel does not signal POLLOUT, no new messages will come from the client. Current code does not do this POLLOUT before sending a messages, but our kdbus client actually does that. It is the right thing to do. And we have been doing this with all of our protocols that are using asynchronous IO. No point in kdbus being any different. Well, kdbus keeps per-reciever buffers only, hence signalling on the kdbus fd when you are able to write is not really possible, since this information is not bound to the sender fd but only to the receiever of which there are many... If I understand you correctly you hence want the kdbus fd to always return EPOLLOUT then, because if a client wants to send something it can do that at any time? If that's the case then POLLOUT should really be ORed into the mask unconditionally, not just in some cases... So, I can sympathize with what you are trying to do. However, I think your patch doesn't do the right thing... It should really OR the POLLOUT into all masks always. always returning POLLOUT is also fine. As long as the fd signals POLLOUT and not just swallows it. Yes, we should add POLLOUT unconditionally. I will push the fix. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: collapse JOB_RELOAD on an inactive unit into JOB_NOP
Lennart Poettering wrote on 18/08/14 15:05: On Fri, 15.08.14 21:10, Michael Biebl (mbi...@gmail.com) wrote: 2014-08-15 12:50 GMT+02:00 Lennart Poettering lenn...@poettering.net: I think most of the confusion here comes from the fact that sysv service restarts don't care about ordering at all, really, and we do. But the answer to that is not to weaken the current strong semantics of blocking, but simply not to request blocking operation at all, i.e. use --no-block, and just queue things in, instead of waiting for them. Note that on FEdora the sysv /sbin/service glue actually adds in --no-block for many cases, too, due to the stricter requirements of systemd there. I just had a look at /sbin/service and/etc/init.d/functions as shipped by F20 and couldn't find any traces of --no-block. I'd be interested to know under what conditions you add --no-block. Ah, sorry, it doesn't use --no-block. But it does use the ignore-dependencies stuff, look for SYSTEMCTL_IGNORE_DEPENDENCIES in /etc/rc.d/init.d/functions. I was always confused why the SYSTEMCTL_IGNORE_DEPENDENCIES hack was used here. In Mageia I used a similarly implemented SYSTEMCTL_NO_BLOCK instead and seems to be fine for our uses. In my head not blocking seems safer than ignoring deps, but I can understand the desire for the service to be ready after the operation is complete... anyway in the places where this was needed for us it didn't seem to matter in practice. Cheers 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] [PATCH kdbus] handle: Return POLLOUT | POLLWRNORM mask when no messages are pending
On 08/18/2014 04:02 PM, Lennart Poettering wrote: On Fri, 15.08.14 14:16, Marcel Holtmann (mar...@holtmann.org) wrote: Blindly sending messages is never a good idea. You want to poll for POLLOUT first. This does not make a big difference for current kernel, but it allows future extensions when the clients are well behaving and just waiting for POLLOUT. Meaning once the kernel does not signal POLLOUT, no new messages will come from the client. Current code does not do this POLLOUT before sending a messages, but our kdbus client actually does that. It is the right thing to do. And we have been doing this with all of our protocols that are using asynchronous IO. No point in kdbus being any different. Well, kdbus keeps per-reciever buffers only, hence signalling on the kdbus fd when you are able to write is not really possible, since this information is not bound to the sender fd but only to the receiever of which there are many... Exactly. If I understand you correctly you hence want the kdbus fd to always return EPOLLOUT then, because if a client wants to send something it can do that at any time? If that's the case then POLLOUT should really be ORed into the mask unconditionally, not just in some cases... Yes, except when the connection is dead. I've pushed a patch to do that, please check. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make journalctl start at the end of the journal by default
В Mon, 18 Aug 2014 16:42:52 +0200 Lennart Poettering lenn...@poettering.net пишет: I am pretty sure doing the auto-paging thing (the same way as git, and others do it) improves end-user experience for most people. I mean, I think having arrow keys is the common case. Not having them is the rare exception... It's not only whether keys are available but also terminal size. Personally I find default (lack of) line wrapping quite annoying - I'm still have to use small notebook with relatively tiny terminal size and default behavior means permanent scrolling right and left to see message itself and its timestamp (or origin) etc. I think line wrapping by default is really more user friendly - with small terminal it allows you to use whole message at once and with large terminal most lines probably fit in the width anyway so there will be no difference. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Link down for systemd articles
Lennart Poettering wrote on 18/08/14 14:19: On Mon, 18.08.14 12:45, Saket Sinha (saket.sinh...@gmail.com) wrote: Hi, I have been working on systemd recently and was referring to articles by Lennart Poettering for the same. However, I am not able to access the articles hosted at the below link - http://0pointer.de/blog/projects/ Is the server down or something ? Somebody found it funny to DoS my server with HTTP or so. I turned HTTP off temporarily. I have now started it again. It might be a nicer long-term goal to move some of the systemd for Administrators/Developers content over to the FDO Wiki. These are super useful articles and it would probably be a good idea to have them somewhere that corrections and fixups could be made too (i.e. when things have been superseded or tweaked slightly since the original article was written) as well as moving them off your own server onto more official infrastructure. Not that I'm personally able to volunteer right at this moment, but perhaps if you approve and put the call out some kind souls might oblige! 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] Work on adding polkit support to systemd1
On Fri, 15.08.14 19:28, Stef Walter (st...@redhat.com) wrote: On 15.08.2014 18:56, Lennart Poettering wrote: On Fri, 15.08.14 18:25, Stef Walter (st...@redhat.com) wrote: On 13.08.2014 20:27, Lennart Poettering wrote: On Wed, 06.08.14 13:23, Stef Walter (st...@redhat.com) wrote: I've done initial work on adding polkit support to systemd1 DBus methods. You can see it here: Thanks for the review. Worked on this a bit more. I might drop off the face of the earth for a couple weeks. In case I do, I thought I'd update my public branch. But if I'm around, I'll test and prepare a patch set early next week. https://github.com/stefwalter/systemd/commits/polkit-systemd1 Hmm, yuck. There's a security issue here... Reading the capabilities from the sender on dbus1 is racy, since we have to read it from /proc/$PID/stat and don't get it sent along with the message, like we do on kdbus. A rogue client could send a message, quickly invoke some suid binary, and we'd consider the client trusted. Now for the low-level implementation of the vtable bit we are actually smart, and check by UID on dbus1, and by cap on kdbus, in order to avoid the vulnerability. Hmm, now I wonder how to best handle this for cases like this, we probably need some generic way how clients can make this decision in an always safe way... I need to think more about this... By the way, there's some similar problematic code in the modified KillUnit() method implementation ... changed from specifying the CAP_KILL in the vtable, and now it does a manual check. Patch set looks great otherwise. I'll come up with something for the security issue, then adapt your patch, and merge it. I haven't tested the updated branch at all :) So it may go boom... I have now pushed this, after reworking this on top some major changes to bus_verify_polkit(), which avoids having to pass the original callbacks through to the function that ultimately does the verification. While merging I also made another change, you are probably not going to like: I turned of the interactivity for the polkit checks. Interactivity needs to be optional, and it currently is for all out polkit-enabled bus methods. And we should do the same for the PID 1 offered methods. Now, of course, we should open this up for inetractive (after all, that's what polkit is good for), but we probably need a new set of methods for that, which take the original arguments but also take a boolean argument to enable ineractivity. Hence, we probably should have StartUnit2() in addition to StartUnit(). 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] man: fix typo
On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: Thanks! Applied! --- man/systemd-firstboot.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd-firstboot.xml b/man/systemd-firstboot.xml index 42fd753..c3fe0ed 100644 --- a/man/systemd-firstboot.xml +++ b/man/systemd-firstboot.xml @@ -249,7 +249,7 @@ termoption--setup-machine-id/option/term paraInitialize the system's machine -ID to a random ID. This only works +ID to a random ID. This only works in combination with option--root=/option./para /varlistentry 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] [PATCHv2 1/2] tmpfiles: only execute chmod()/chown() when needed
On Sun, 17.08.14 09:45, Michael Olbrich (m.olbr...@pengutronix.de) wrote: This avoids errors like this, when the paths are already there with the correct permissions and owner: chmod(/var/spool) failed: Read-only file system Applied! Thanks! The original code checked for 'stat() = 0'. Any reason for that? My man-page says 'On success, zero is returned'. Well, I usually check for 0 on failure and = 0 on success. It's usually how things are done, on libc, and on our own code (our code just gets one step further and returns -errno on error... But yeah, it's not much of a difference, both works, but I think it's slightly clearer to just check for negativity/non-negativity, since usually positive values indicate non-errors, and negative ones errors, even if in this case one can check for less. Or to turn this around: if stat() would someday return 1 instead of 0, for some reason, then I'd assume that this wouldn#t indicate an error, but just some other form of success... 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] condition-util: do not validate condition if paramater is garbage
On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
To follow the same behavior that src/core/condition.c do
---
src/shared/condition-util.c| 2 +-
src/test/test-condition-util.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/shared/condition-util.c b/src/shared/condition-util.c
index ff4a8ec..f21786f 100644
--- a/src/shared/condition-util.c
+++ b/src/shared/condition-util.c
@@ -213,7 +213,7 @@ bool condition_test_ac_power(Condition *c) {
r = parse_boolean(c-parameter);
if (r 0)
-return !c-negate;
+return c-negate;
Idon't agree that this would be a good idea. I am pretty sure that if we
cannot make sense of the ac power condition we should return positive by
default, not negative.
That's a bit different form the other conditions, but this is simply
because if don't know let's say a virtualization it's probably a good
idea to assume that we are not running on it. However, if we can't make
sense of an AC state, we should probably assume that we have AC power
and hence say true...
Does that make sense?
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] Implementing resume from hibernation as a systemd unit file
On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. Well, in the initrd the root dir is mounted to /sysroot, which means you should be able to order yourself before sysroot.mount. 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 1/2] label: move selinux label APIs to its util file
On Mon, 18.08.14 22:40, WaLyong Cho (walyong@samsung.com) wrote:
On 08/18/2014 10:09 PM, Lennart Poettering wrote:
On Mon, 18.08.14 15:06, WaLyong Cho (walyong@samsung.com) wrote:
And add prefix selinux_ to each APIs like smack.
I am a bit concerned about this, as selinux_ is really the prefix the
selinux libraries use for most of their newer symbols. And they have a
lot of symbols that actually are named very similar to ours (given that
ours are just wrappers for them anyway to just make their apis more
digestable...). libselinux is quite chaotic, they also use the
selabel_ prefix sometimes, and sometimes no prefix it all. Other times
they use the security_ prefix. Seems they really didn't understand the
concept of namespacing in C...
Anyway, maybe we can find a different prefix to use. selnx_ or so? Not
pretty, but at least distinct? sel_? se_linux_? util_selinux?
or maybe we just call call our internal selinux apis
label_selinux_xyz, and our smack apis label_smack_xyz?
Or maybe mac_selinux_xyz and mac_smack_xyz?
I think the latter sounds most appropriate to me right now, as it is
still somewhat short, and sufficiently distinctive. I'd probably go for
that. Any other suggestions?
Both sounds good.
How does we do on filename?
label-selinux.{c/h} and label-smack.{c/h}?
Or
mac.{c/h}, mac-selinux.{c/h} and mac-smack.{c/h}?
Maybe selinux-label.c/h, smack-label.ch and so on?
That way it would fit relatively nicely with selinux-access.c/h,
selinux-setup.c/h, and so on..
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 8/8] tests: add missing entry to test-tables
On Sat, 16.08.14 14:19, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
All 8 applied! Thanks!
---
src/test/test-tables.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/test/test-tables.c b/src/test/test-tables.c
index cb9185e..88e7d10 100644
--- a/src/test/test-tables.c
+++ b/src/test/test-tables.c
@@ -86,6 +86,7 @@ int main(int argc, char **argv) {
test_table(policy_item_type, POLICY_ITEM_TYPE);
test_table(protect_home, PROTECT_HOME);
test_table(protect_system, PROTECT_SYSTEM);
+test_table(rlimit, RLIMIT);
test_table(scope_result, SCOPE_RESULT);
test_table(scope_state, SCOPE_STATE);
test_table(service_exec_command, SERVICE_EXEC_COMMAND);
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). I don't know if I'll get to it today, but I'll try to do it ASAP. I did not try latest git, and I'd like to avoid it on real hardware if possible. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. I didn't know you can simply fix anything in the kernel. With the general inertia of kernel development, such a fix would take between 4 and 6 months to be available in a mainline release. Personally, I'd opt for the two-step process with ioctl+rtnl, which we could drop as soon as a new rtnl interface has existed for some time. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. That was my first idea (before I even considered using a .netdev unit), since the tap interface was created by vde_switch. Here's the thing: .link units cannot match on names. There is no workaround for this problem with networkd only. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Impossible to enable instantiated symlink (foo@bar)
If foo@bar.service symlink is present, it is impossible to enable it: bor@opensuse:~ ll /run/systemd/system итого 8 lrwxrwxrwx 1 root root 32 авг 18 21:06 foo@bar.service - /run/systemd/system/foo@.service -rwxr-xr-x 1 root root 1032 авг 18 21:06 foo@.service bor@opensuse:~ sudo systemctl enable foo@bar.service Failed to issue method call: No such file or directory bor@opensuse:~ The problem is, unit_file_search() is called with allow_symlink=false when used in enable codepath, which means that every attempt to open will end up wither in ELOOP or ENOENT. At the end it exits with the last error (ENOENT in this case, but this obviously depends on in which directory symlink is created). Is it really intentional? I'm actually all for disallowing such symlinks :) but in this case at least meaningful error message is required. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impossible to enable instantiated symlink (foo@bar)
On Mon, 18.08.14 21:10, Andrei Borzenkov (arvidj...@gmail.com) wrote: If foo@bar.service symlink is present, it is impossible to enable it: bor@opensuse:~ ll /run/systemd/system итого 8 lrwxrwxrwx 1 root root 32 авг 18 21:06 foo@bar.service - /run/systemd/system/foo@.service -rwxr-xr-x 1 root root 1032 авг 18 21:06 foo@.service bor@opensuse:~ sudo systemctl enable foo@bar.service Failed to issue method call: No such file or directory bor@opensuse:~ The problem is, unit_file_search() is called with allow_symlink=false when used in enable codepath, which means that every attempt to open will end up wither in ELOOP or ENOENT. At the end it exits with the last error (ENOENT in this case, but this obviously depends on in which directory symlink is created). Is it really intentional? I'm actually all for disallowing such symlinks :) but in this case at least meaningful error message is required. Happy to take a patch which fixes the error to ELOOP if we hit ELOOP at least once! 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
On Mon, Aug 18, 2014 at 7:02 PM, Thomas Bächler tho...@archlinux.org wrote: 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). I don't know if I'll get to it today, but I'll try to do it ASAP. I did not try latest git, and I'd like to avoid it on real hardware if possible. Thanks. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. I didn't know you can simply fix anything in the kernel. Well, people could always backport. But I agree, it is slow work. The patch itself should not be many lines though. With the general inertia of kernel development, such a fix would take between 4 and 6 months to be available in a mainline release. Personally, I'd opt for the two-step process with ioctl+rtnl, which we could drop as soon as a new rtnl interface has existed for some time. I'm hesitant to add the rtnl+ioctl work-around though, it would probably mean that a real fix would never be made, and after all this is just a missing feature rather than a real bug. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. That was my first idea (before I even considered using a .netdev unit), since the tap interface was created by vde_switch. Here's the thing: .link units cannot match on names. There is no workaround for this problem with networkd only. Indeed, you are right, the .link unit will not work. One would have to write a custom udev rule. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impossible to enable instantiated symlink (foo@bar)
В Mon, 18 Aug 2014 19:22:01 +0200 Lennart Poettering lenn...@poettering.net пишет: On Mon, 18.08.14 21:10, Andrei Borzenkov (arvidj...@gmail.com) wrote: If foo@bar.service symlink is present, it is impossible to enable it: bor@opensuse:~ ll /run/systemd/system итого 8 lrwxrwxrwx 1 root root 32 авг 18 21:06 foo@bar.service - /run/systemd/system/foo@.service -rwxr-xr-x 1 root root 1032 авг 18 21:06 foo@.service bor@opensuse:~ sudo systemctl enable foo@bar.service Failed to issue method call: No such file or directory bor@opensuse:~ The problem is, unit_file_search() is called with allow_symlink=false when used in enable codepath, which means that every attempt to open will end up wither in ELOOP or ENOENT. At the end it exits with the last error (ENOENT in this case, but this obviously depends on in which directory symlink is created). Is it really intentional? I'm actually all for disallowing such symlinks :) but in this case at least meaningful error message is required. Happy to take a patch which fixes the error to ELOOP if we hit ELOOP at least once! On a minor note, I do not think Too many symbolic links encountered would be better error message here. But more seriously - this is highly inconsistent. In this case such synlinks must be disallowed everywhere - currently systemctl enable fails but systemctl start succeeds. So I have to ask once more - is intention to disallow such symlinks globally? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Monday 18 August 2014 at 18:40:59, Lennart Poettering wrote: On Mon, 18.08.14 18:00, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Monday 18 August 2014 at 15:57:25, Lennart Poettering wrote: On Fri, 15.08.14 15:35, Ivan Shapovalov (intelfx...@gmail.com) wrote: That should be enough. (You don't need to individually order the systemd-fsck@.service instances for the other devices after your service, since they are already ordered after systemd-fsck-root.service, and you order yourself before that, so all is good). One more question. What about setups with no initrd and read-write rootfs? In such cases, the resume unit must silently skip itself. ConditionPathIsReadWrite=!/ doesn't seem to be useful here: with initramfs this check will yield a false-negative. I am pretty sure the hibernation stuff should only be supported when an initrd is used. And in that case we should simply not pull in the hibernation service into the non-initrd initial transaction (or in other words, only pull it in by initrd.target, but not otherwise). Even if initramfs-only, ordering dependencies still need to be worked out. Inside of initramfs, neither systemd-fsck-root.service nor systemd-remount-fs.service do exist, so there's apparently nothing to reliably order against. Well, in the initrd the root dir is mounted to /sysroot, which means you should be able to order yourself before sysroot.mount. Lennart ...missing sysroot's fsck, as well as any other x-initrd mounts and their fsck instances. Seems that sysroot.mount alone isn't sufficient. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] bus-control: Fix cgroup handling
On systems without properly setup systemd, cg_get_root_path returns
-ENOENT. This means that busctl doesn't display much information.
busctl monitor also fails whenever it intercepts messages.
This fix fakes creates a fake / root cgroup which lets busctl work
on such systems.
---
src/libsystemd/sd-bus/bus-control.c | 8 +++-
src/libsystemd/sd-bus/bus-internal.h | 2 ++
src/libsystemd/sd-bus/bus-kernel.c | 8 +++-
src/libsystemd/sd-bus/sd-bus.c | 18 ++
4 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-control.c
b/src/libsystemd/sd-bus/bus-control.c
index 076bbce..ad372f6 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -495,11 +495,9 @@ static int bus_get_owner_kdbus(
goto fail;
}
-if (!bus-cgroup_root) {
-r =
cg_get_root_path(bus-cgroup_root);
-if (r 0)
-goto fail;
-}
+r = bus_get_root_path(bus);
+if (r 0)
+goto fail;
c-cgroup_root = strdup(bus-cgroup_root);
if (!c-cgroup_root) {
diff --git a/src/libsystemd/sd-bus/bus-internal.h
b/src/libsystemd/sd-bus/bus-internal.h
index 618e82c..8827061 100644
--- a/src/libsystemd/sd-bus/bus-internal.h
+++ b/src/libsystemd/sd-bus/bus-internal.h
@@ -381,3 +381,5 @@ int bus_set_address_system_remote(sd_bus *b, const char
*host);
int bus_set_address_system_container(sd_bus *b, const char *machine);
int bus_remove_match_by_string(sd_bus *bus, const char *match,
sd_bus_message_handler_t callback, void *userdata);
+
+int bus_get_root_path(sd_bus *bus);
diff --git a/src/libsystemd/sd-bus/bus-kernel.c
b/src/libsystemd/sd-bus/bus-kernel.c
index 8b961c3..9073b3c 100644
--- a/src/libsystemd/sd-bus/bus-kernel.c
+++ b/src/libsystemd/sd-bus/bus-kernel.c
@@ -542,11 +542,9 @@ static int bus_kernel_make_message(sd_bus *bus, struct
kdbus_msg *k) {
m-creds.cgroup = d-str;
m-creds.mask |=
(SD_BUS_CREDS_CGROUP|SD_BUS_CREDS_UNIT|SD_BUS_CREDS_USER_UNIT|SD_BUS_CREDS_SLICE|SD_BUS_CREDS_SESSION|SD_BUS_CREDS_OWNER_UID)
bus-creds_mask;
-if (!bus-cgroup_root) {
-r = cg_get_root_path(bus-cgroup_root);
-if (r 0)
-goto fail;
-}
+r = bus_get_root_path(bus);
+if (r 0)
+goto fail;
m-creds.cgroup_root = bus-cgroup_root;
diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index 0fadd16..7febf3c 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -3330,3 +3330,21 @@ _public_ int sd_bus_get_name(sd_bus *bus, const char
**name) {
*name = bus-connection_name;
return 0;
}
+
+int bus_get_root_path(sd_bus *bus) {
+int r;
+
+if (bus-cgroup_root)
+return 0;
+
+r = cg_get_root_path(bus-cgroup_root);
+if (r == -ENOENT) {
+bus-cgroup_root = strdup(/);
+if (!bus-cgroup_root)
+return -ENOMEM;
+
+r = 0;
+}
+
+return r;
+}
--
1.8.5.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] condition-util: do not validate condition if paramater is garbage
2014-08-18 18:34 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
To follow the same behavior that src/core/condition.c do
---
src/shared/condition-util.c| 2 +-
src/test/test-condition-util.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/shared/condition-util.c b/src/shared/condition-util.c
index ff4a8ec..f21786f 100644
--- a/src/shared/condition-util.c
+++ b/src/shared/condition-util.c
@@ -213,7 +213,7 @@ bool condition_test_ac_power(Condition *c) {
r = parse_boolean(c-parameter);
if (r 0)
-return !c-negate;
+return c-negate;
Idon't agree that this would be a good idea. I am pretty sure that if we
cannot make sense of the ac power condition we should return positive by
default, not negative.
That's a bit different form the other conditions, but this is simply
because if don't know let's say a virtualization it's probably a good
idea to assume that we are not running on it. However, if we can't make
sense of an AC state, we should probably assume that we have AC power
and hence say true...
Does that make sense?
Both make sense for me, there is no good thing to assume for this, but
I just thought that the same behaviour should be followed and document
about it maybe.
By the way, there is a couple of places, like this one, where we
should add a warning when we could not parse the boolean, I think.
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] util: do not execute files without exec permission
2014-08-18 15:51 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
What's the rationale here? I think it makes a lot of sense to output an
error if people drop non-executable files in such a directory...
Yeah it makes sense. But it is useless to fork exec() when we know
it will fail so maybe leave the check and add a warning ?
---
src/shared/util.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/shared/util.c b/src/shared/util.c
index 18d40f3..3a03470 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3921,6 +3921,10 @@ void execute_directory(const char *directory, DIR *d,
usec_t timeout, char *argv
_exit(EXIT_FAILURE);
}
+if (access(path, X_OK) 0) {
+continue;
+}
+
pid = fork();
if (pid 0) {
log_error(Failed to fork: %m);
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] pager: wrap long lines by default
Wrap lines longer than the screen width to multiple rows instead of
making them stumble abruptly off the edge.
---
man/less-variables.xml | 2 +-
src/shared/pager.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/man/less-variables.xml b/man/less-variables.xml
index 09cbd42..4264692 100644
--- a/man/less-variables.xml
+++ b/man/less-variables.xml
@@ -23,7 +23,7 @@
listitemparaOverride the default
options passed to
commandless/command
-(literalFRSXMK/literal)./para/listitem
+(literalFRXMK/literal)./para/listitem
/varlistentry
/variablelist
/refsect1
diff --git a/src/shared/pager.c b/src/shared/pager.c
index 5479094..4eefe96 100644
--- a/src/shared/pager.c
+++ b/src/shared/pager.c
@@ -91,7 +91,7 @@ int pager_open(bool jump_to_end) {
less_opts = getenv(SYSTEMD_LESS);
if (!less_opts)
-less_opts = FRSXMK;
+less_opts = FRXMK;
if (jump_to_end)
less_opts = strappenda(less_opts, +G);
setenv(LESS, less_opts, 1);
--
2.0.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Impossible to enable instantiated symlink (foo@bar)
On Mon, 18.08.14 21:52, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Mon, 18 Aug 2014 19:22:01 +0200 Lennart Poettering lenn...@poettering.net пишет: On Mon, 18.08.14 21:10, Andrei Borzenkov (arvidj...@gmail.com) wrote: If foo@bar.service symlink is present, it is impossible to enable it: bor@opensuse:~ ll /run/systemd/system итого 8 lrwxrwxrwx 1 root root 32 авг 18 21:06 foo@bar.service - /run/systemd/system/foo@.service -rwxr-xr-x 1 root root 1032 авг 18 21:06 foo@.service bor@opensuse:~ sudo systemctl enable foo@bar.service Failed to issue method call: No such file or directory bor@opensuse:~ The problem is, unit_file_search() is called with allow_symlink=false when used in enable codepath, which means that every attempt to open will end up wither in ELOOP or ENOENT. At the end it exits with the last error (ENOENT in this case, but this obviously depends on in which directory symlink is created). Is it really intentional? I'm actually all for disallowing such symlinks :) but in this case at least meaningful error message is required. Happy to take a patch which fixes the error to ELOOP if we hit ELOOP at least once! On a minor note, I do not think Too many symbolic links encountered would be better error message here. But more seriously - this is highly inconsistent. In this case such synlinks must be disallowed everywhere - currently systemctl enable fails but systemctl start succeeds. So I have to ask once more - is intention to disallow such symlinks globally? No. Symlinks are what systemctl enable and systemctl disable manage, based on the data of [Install] sections. We want to make sure that clearly separate the configuration state from the vendor data here, hence never follow symlinks when enabling/disabling something, but we do follow them with systemctl start and systemctl stop during runtime. 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] Make journalctl start at the end of the journal by default
On 18 August 2014 17:33, Andrei Borzenkov arvidj...@gmail.com wrote: Personally I find default (lack of) line wrapping quite annoying [...] I think line wrapping by default is really more user friendly. Agreed. I assume there was a good reason to add -S to the default pager options, but I can't imagine what it would be. I've a patch applied locally that removes it, because I'm fussy that way. I'd sent it, but it's ridiculously trivial T G-R PS: oh hell, I'm staring at it anyway. Here you go. Might save someone 4 seconds of grepping. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2] bootchart: use NSEC_PER_SEC
---
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] [PATCH] man: fix typo
--- man/systemd.exec.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index cfcf996..af103ff 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -1013,7 +1013,7 @@ made inaccessible and empty for processes invoked by this unit. If set to literalread-only/literal, the -two directores are made read-only +two directories are made read-only instead. It is recommended to enable this setting for all long-running services (in particular network-facing -- 2.0.4 ___ 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 Mon, 18.08.14 20:59, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
Thanks! Applied!
---
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) {
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] man: fix typo
On Mon, 18.08.14 21:00, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: Thanks! Applied! --- man/systemd.exec.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index cfcf996..af103ff 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -1013,7 +1013,7 @@ made inaccessible and empty for processes invoked by this unit. If set to literalread-only/literal, the -two directores are made read-only +two directories are made read-only instead. It is recommended to enable this setting for all long-running services (in particular network-facing 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] [PATCHv2] bus-control: Fix cgroup handling
On Mon, 18.08.14 13:21, Denis Kenzior (denk...@gmail.com) wrote:
Thanks! Applied!
On systems without properly setup systemd, cg_get_root_path returns
-ENOENT. This means that busctl doesn't display much information.
busctl monitor also fails whenever it intercepts messages.
This fix fakes creates a fake / root cgroup which lets busctl work
on such systems.
---
src/libsystemd/sd-bus/bus-control.c | 8 +++-
src/libsystemd/sd-bus/bus-internal.h | 2 ++
src/libsystemd/sd-bus/bus-kernel.c | 8 +++-
src/libsystemd/sd-bus/sd-bus.c | 18 ++
4 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-control.c
b/src/libsystemd/sd-bus/bus-control.c
index 076bbce..ad372f6 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -495,11 +495,9 @@ static int bus_get_owner_kdbus(
goto fail;
}
-if (!bus-cgroup_root) {
-r =
cg_get_root_path(bus-cgroup_root);
-if (r 0)
-goto fail;
-}
+r = bus_get_root_path(bus);
+if (r 0)
+goto fail;
c-cgroup_root = strdup(bus-cgroup_root);
if (!c-cgroup_root) {
diff --git a/src/libsystemd/sd-bus/bus-internal.h
b/src/libsystemd/sd-bus/bus-internal.h
index 618e82c..8827061 100644
--- a/src/libsystemd/sd-bus/bus-internal.h
+++ b/src/libsystemd/sd-bus/bus-internal.h
@@ -381,3 +381,5 @@ int bus_set_address_system_remote(sd_bus *b, const char
*host);
int bus_set_address_system_container(sd_bus *b, const char *machine);
int bus_remove_match_by_string(sd_bus *bus, const char *match,
sd_bus_message_handler_t callback, void *userdata);
+
+int bus_get_root_path(sd_bus *bus);
diff --git a/src/libsystemd/sd-bus/bus-kernel.c
b/src/libsystemd/sd-bus/bus-kernel.c
index 8b961c3..9073b3c 100644
--- a/src/libsystemd/sd-bus/bus-kernel.c
+++ b/src/libsystemd/sd-bus/bus-kernel.c
@@ -542,11 +542,9 @@ static int bus_kernel_make_message(sd_bus *bus, struct
kdbus_msg *k) {
m-creds.cgroup = d-str;
m-creds.mask |=
(SD_BUS_CREDS_CGROUP|SD_BUS_CREDS_UNIT|SD_BUS_CREDS_USER_UNIT|SD_BUS_CREDS_SLICE|SD_BUS_CREDS_SESSION|SD_BUS_CREDS_OWNER_UID)
bus-creds_mask;
-if (!bus-cgroup_root) {
-r = cg_get_root_path(bus-cgroup_root);
-if (r 0)
-goto fail;
-}
+r = bus_get_root_path(bus);
+if (r 0)
+goto fail;
m-creds.cgroup_root = bus-cgroup_root;
diff --git a/src/libsystemd/sd-bus/sd-bus.c b/src/libsystemd/sd-bus/sd-bus.c
index 0fadd16..7febf3c 100644
--- a/src/libsystemd/sd-bus/sd-bus.c
+++ b/src/libsystemd/sd-bus/sd-bus.c
@@ -3330,3 +3330,21 @@ _public_ int sd_bus_get_name(sd_bus *bus, const char
**name) {
*name = bus-connection_name;
return 0;
}
+
+int bus_get_root_path(sd_bus *bus) {
+int r;
+
+if (bus-cgroup_root)
+return 0;
+
+r = cg_get_root_path(bus-cgroup_root);
+if (r == -ENOENT) {
+bus-cgroup_root = strdup(/);
+if (!bus-cgroup_root)
+return -ENOMEM;
+
+r = 0;
+}
+
+return r;
+}
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] condition-util: do not validate condition if paramater is garbage
On Mon, 18.08.14 20:33, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: By the way, there is a couple of places, like this one, where we should add a warning when we could not parse the boolean, I think. yeah, we should. but this is actually not as easy as it sounds, since we really should generate such warning while parsing the unit files, not only when we test the conditions later on. But the current code really doesn't make that easy... 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] util: do not execute files without exec permission
On Mon, 18.08.14 20:47, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: 2014-08-18 15:51 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: What's the rationale here? I think it makes a lot of sense to output an error if people drop non-executable files in such a directory... Yeah it makes sense. But it is useless to fork exec() when we know it will fail so maybe leave the check and add a warning ? Dunno. Is this a real problem? I mean, failing after the fork() shouldn't be much of a real-life problem, since it realistically never really happens. In general I always try to be careful with these cases that might be vulnerable TOCTTOU issues. Not that this was really an issue in this case, but I'd prefer if the kernel's exec() syscall would figure out that something isn't executable, rather than us, since we cannot do it atomically, and somebody could toggle the x bit of a file right after we ran access() on it, but before the exec()... Hence, I'd prefer to avoid any explicit access() check, unless we really know that this is a common issue. Hope that makes sense, 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] util: do not execute files without exec permission
2014-08-18 21:10 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Mon, 18.08.14 20:47, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: 2014-08-18 15:51 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Sat, 16.08.14 14:24, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: What's the rationale here? I think it makes a lot of sense to output an error if people drop non-executable files in such a directory... Yeah it makes sense. But it is useless to fork exec() when we know it will fail so maybe leave the check and add a warning ? Dunno. Is this a real problem? I mean, failing after the fork() shouldn't be much of a real-life problem, since it realistically never really happens. In general I always try to be careful with these cases that might be vulnerable TOCTTOU issues. Not that this was really an issue in this case, but I'd prefer if the kernel's exec() syscall would figure out that something isn't executable, rather than us, since we cannot do it atomically, and somebody could toggle the x bit of a file right after we ran access() on it, but before the exec()... Hence, I'd prefer to avoid any explicit access() check, unless we really know that this is a common issue. Hope that makes sense, Yeah it totally makes sense. 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] Logind error - Failed to abandon session scope: Connection reset
Hello Lennart, 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? 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. Thanks, Roger On 18/08/2014 11:53 PM, Lennart Poettering wrote: On Sun, 17.08.14 14:48, Roger Qiu (roger@polycademy.com) wrote: Hello Lennart, The reason why you don't want explicit ordering is because of a slower boot time? Well, we want to keep things simple and as parallel as possible. Yes. And we don#t want to add dependencies that won't be necessary on kdbus, unless we really have to. When you are referring to patching them out, would that be from upstream systemd/logind? Yeah. Just downgrading them to a debug log message should be enough. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] kdbus: metadata improvements
Hi, Patch 1 and 2 should be applied. For patch 3 it can be discussed :-) Please apply on top of the test series that contain the test-kdbus-metadta-ns tool. Thanks! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] metadata: document creds_item_off and auxgrps_item_off fields
Signed-off-by: Djalal Harouni tix...@opendz.org --- metadata.c | 3 ++- metadata.h | 8 +++- 2 files changed, 9 insertions(+), 2 deletions(-) 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. -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] connection: move the install creds into the slice to its own function
Move the install creds into the receiver's slice to its own function
kdbus_conn_creds_install().
Use from_kuid_munged(), so the uid mapping never fails.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
connection.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/connection.c b/connection.c
index 99ac2a1..9250dab 100644
--- a/connection.c
+++ b/connection.c
@@ -964,6 +964,25 @@ remove_unused:
return ret;
}
+static int kdbus_conn_creds_install(struct kdbus_conn_queue *queue)
+{
+ int ret;
+ struct kdbus_creds creds = {};
+ struct user_namespace *current_ns = current_user_ns();
+ off_t off = queue-creds_item_offset +
+ offsetof(struct kdbus_item, creds);
+
+ creds.uid = from_kuid_munged(current_ns, queue-uid);
+ creds.gid = from_kgid_munged(current_ns, queue-gid);
+ creds.pid = pid_nr_ns(queue-pid, task_active_pid_ns(current));
+ creds.tid = pid_nr_ns(queue-tid, task_active_pid_ns(current));
+
+ ret = kdbus_pool_slice_copy_user(queue-slice, off,
+creds, sizeof(creds));
+
+ return ret;
+}
+
static int kdbus_conn_msg_install(struct kdbus_conn_queue *queue)
{
int *memfds = NULL;
@@ -989,18 +1008,7 @@ static int kdbus_conn_msg_install(struct kdbus_conn_queue
*queue)
}
if (queue-creds_item_offset) {
- struct kdbus_creds creds;
- size_t size = sizeof(__u64) * 4;
- off_t off = queue-creds_item_offset +
- offsetof(struct kdbus_item, creds);
-
- creds.uid = from_kuid(current_user_ns(), queue-uid);
- creds.gid = from_kgid(current_user_ns(), queue-gid);
- creds.pid = pid_nr_ns(queue-pid, task_active_pid_ns(current));
- creds.tid = pid_nr_ns(queue-tid, task_active_pid_ns(current));
-
- ret = kdbus_pool_slice_copy_user(queue-slice, off,
-creds, size);
+ ret = kdbus_conn_creds_install(queue);
if (ret 0)
goto exit_rewind_fds;
}
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] kdbus: get some creds during meta append for optimization
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;
+};
+
+/**
* struct kdbus_conn_queue - messages waiting to be read
* @entry: Entry in the connection's list
* @prio_node: Entry in the priority queue tree
@@ -67,10 +85,8 @@ struct kdbus_conn_reply;
* @auxgrp_item_offset:The offset of the auxgrp item inside the slice,
if
* the user requested this metainfo in its attach flags.
* 0 if unused.
- * @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
+ * @qcreds The creds that must be translated before
+ * installing.
* @auxgrps: An array storing the sender's aux groups, in kgid_t.
* This information is translated into the user's
* namespace when the message is installed.
@@ -97,10 +113,7 @@ struct kdbus_conn_queue {
off_t auxgrp_item_offset;
/* to honor namespaces, we have to store the following here */
- kuid_t uid;
- kgid_t gid;
- struct pid *pid;
- struct pid *tid;
+ struct kdbus_queue_creds qcreds;
kgid_t *auxgrps;
unsigned int auxgrps_count;
@@ -466,10 +479,11 @@ static void kdbus_conn_queue_remove(struct kdbus_conn
*conn,
static void kdbus_conn_queue_cleanup(struct kdbus_conn_queue *queue)
{
- if (queue-pid)
- put_pid(queue-pid);
- if (queue-tid)
- put_pid(queue-tid);
+ struct kdbus_queue_creds *qcreds = queue-qcreds;
+ if (qcreds-pid)
+ put_pid(qcreds-pid);
+ if (qcreds-tid)
+ put_pid(qcreds-tid);
if (queue-auxgrps)
kfree(queue-auxgrps);
@@ -618,6 +632,7 @@ static int kdbus_conn_queue_alloc(struct kdbus_conn *conn,
/* append message metadata/credential items */
if (meta_off 0) {
struct kdbus_meta *meta = kmsg-meta;
+ struct kdbus_queue_creds *qcreds = queue-qcreds;
/*
* If the receiver requested credential information, store the
@@ -626,10 +641,10 @@ static int kdbus_conn_queue_alloc(struct kdbus_conn *conn,
*/
if (meta-attached KDBUS_ATTACH_CREDS) {
/* store kernel-view of the credentials */
- queue-uid = current_uid();
- queue-gid = current_gid();
- queue-pid = get_task_pid(current, PIDTYPE_PID);
- queue-tid = get_task_pid(current-group_leader,
+ qcreds-uid = meta-mcreds.uid;
+ qcreds-gid = meta-mcreds.gid;
+ qcreds-pid = get_task_pid(current, PIDTYPE_PID);
+ qcreds-tid = get_task_pid(current-group_leader,
PIDTYPE_PID);
queue-creds_item_offset = meta_off +
@@ -968,14 +983,15 @@ static int kdbus_conn_creds_install(struct
kdbus_conn_queue *queue)
{
int ret;
struct kdbus_creds creds = {};
+ struct kdbus_queue_creds *qcreds = queue-qcreds;
struct user_namespace
