[systemd-devel] stunnel now supports socket activation
Mark Theunissen, part of the team here at Pantheon, got our changes upstream in version 5.05: https://www.stunnel.org/sdf_ChangeLog.html Progress! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should user mode linux register with machined?
On Fri, Oct 10, 2014 at 06:44:03PM +0200, Lennart Poettering wrote: On Wed, 17.09.14 10:24, Richard Weinberger (richard.weinber...@gmail.com) wrote: On Wed, Sep 17, 2014 at 1:09 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Sep 16, 2014 at 05:31:05PM +0200, Thomas Meyer wrote: Hi, I wrote a small patch for user-mode linux to register with machined by calling CreateMachine. Is this a good idea to do so? Yes, this sounds useful. After all is just another mechanism of virtualization, and in this case can be treated similarly to containers and vms. I still want a sane reason and a usecase for that. Can someone please educate me? :-) Please note that also qemu does not register itself to systemd. libvirt does. I think going down this path makes also sense for UML as libvirt has a UML driver too. qemu and the UML ELF image are the low level building blocks. Managers like libvirt should register the virtual machines created by LXC, UML, qemu, etc.. to systemd. It's a bit more complex. While UML, qemu, kvm, currently don't, LXC, systemd-nspawn and libvirt-lxc all do talk directly to machined. (Note that LXC and libvirt-lxc are separate codebases, the latter is *not* a wrapper around the former). Libvirt registers both LXC QEMU/KVM guests with machined. We don't currently register UML guests with machined, but that is simply because UML isn't really a high priority target for people anymore and so hasn't been updated to use libvirt's cgroup/systemd integration support. From the libvirt POV i'd be happy to see patches to make it register with machined. I'm not sure that standalone UML binaries need to directly integrate/register with systemd - I tend to view it as a job for whatever is managing UML to decide todo that. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-resolved D-Bus API documentation
Is there some documentation of the D-Bus API and its expected behavior? And is there a way to dump the contents of the internal cache? -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] odd seek_tail behaviour
Christian Hesse l...@eworm.de on Mon, 2014/10/13 23:56:
Christian Hesse l...@eworm.de on Mon, 2014/10/13 20:22:
Daurnimator q...@daurnimator.com on Mon, 2014/10/13 01:27:
Hi All,
I was trying to write a program that tailed the journal, but found that
sd_journal_seek_tail() didn't work as expected.
That is: that it would seek to the last/most recent thing in the
journal, and I could tail things from there.
I whipped up a quick demonstration program, that shows that messages I
'next' through, are before the 'cutoff':
[code and output]
Is this behaviour expected? I'm using systemd 216.
I do see a similar problem in my code [0]. I do call sd_journal_previous()
after sd_journal_seek_tail(), but I still do see some older message come
up.
sd_journal_next() is the first I call in while loop. Perhaps even this is
a problem?
[0]
https://github.com/eworm-de/journal-notify/blob/master/journal-notify.c
Looks like I was right. For any reason sd_journal_next() can jump to old
journal entries (even if sd_journal_previous() has been called before). That
happens before sd_journal_wait() is called the first time.
Sadly I do not know how to reproduce. It happens very seldom and I could not
find the culprit so far.
Actually the problem happens before. I have an old entry selected after
calling sd_journal_previous().
Mhh, does adding matches (sd_journal_add_match(),
sd_journal_add_conjunction() and sd_journal_add_disjunction()) have an effect
to sd_journal_seek_tail() and sd_journal_previous()?
Looks like the problem goes away if I seek to tail first, then add my matches.
--
main(a){char*c=/*Schoene Gruesse */B?IJj;MEH
CX:;,b;for(a/*Chris get my mail address:*/=0;b=c[a++];)
putchar(b-1/(/* gcc -o sig sig.c ./sig*/b/42*2-3)*42);}
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxyd: add missing flag translation for RequestName
---
src/bus-proxyd/bus-proxyd.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index 52498f3..6ff0e8c 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -845,7 +845,7 @@ static int process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m) {
} else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus,
RequestName)) {
const char *name;
-uint32_t flags;
+uint32_t flags, param;
r = sd_bus_message_read(m, su, name, flags);
if (r 0)
@@ -856,7 +856,15 @@ static int process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m) {
if ((flags
~(BUS_NAME_ALLOW_REPLACEMENT|BUS_NAME_REPLACE_EXISTING|BUS_NAME_DO_NOT_QUEUE))
!= 0)
return synthetic_reply_method_errno(m, -EINVAL, NULL);
-r = sd_bus_request_name(a, name, flags);
+param = 0;
+if (flags BUS_NAME_ALLOW_REPLACEMENT)
+param |= SD_BUS_NAME_ALLOW_REPLACEMENT;
+if (flags BUS_NAME_REPLACE_EXISTING)
+param |= SD_BUS_NAME_REPLACE_EXISTING;
+if (!(flags BUS_NAME_DO_NOT_QUEUE))
+param |= SD_BUS_NAME_QUEUE;
+
+r = sd_bus_request_name(a, name, param);
if (r 0) {
if (r == -EEXIST)
return synthetic_reply_method_return(m, u,
BUS_NAME_EXISTS);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: only change device permissions if mknod succeeded
https://bugzilla.redhat.com/show_bug.cgi?id=1147248
---
src/tmpfiles/tmpfiles.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 8108b43..ae0289d 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -824,6 +824,7 @@ static int create_item(Item *i) {
case CREATE_BLOCK_DEVICE:
case CREATE_CHAR_DEVICE: {
mode_t file_type;
+bool mknod_succeeded;
if (have_effective_cap(CAP_MKNOD) == 0) {
/* In a container we lack CAP_MKNOD. We
@@ -842,6 +843,7 @@ static int create_item(Item *i) {
r = mknod(i-path, i-mode | file_type,
i-major_minor);
label_context_clear();
}
+mknod_succeeded = (r == 0);
if (r 0) {
if (errno == EPERM) {
@@ -881,10 +883,11 @@ static int create_item(Item *i) {
}
}
-r = item_set_perms(i, i-path);
-if (r 0)
-return r;
-
+if (mknod_succeeded) {
+r = item_set_perms(i, i-path);
+if (r 0)
+return r;
+}
break;
}
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to use cgroups for Tracker?
Hello all, Recently I've started looking into support for cgroups due to this bug: http://bugzilla.gnome.org/show_bug.cgi?id=737663 It was suggested I ask you guys to see what the best way forward would be here. It seems there are different opinions about how to do this including: a) allow the session manager to take care of it. b) do it ourselves in Tracker. c) do nothing, fallback to cgroups per user which are already in place (depending on distro I guess). I personally would rather have a backup plan and go for b) because Tracker processes are not always spawned the same way. What I had in mind to do, was to use a config file with libcgroup and load it in at runtime for processes that are heavy on I/O, CPU and/or Memory. From what I understand, this would require permissions to install the profile at some point (installation? of Tracker) and then just call upon that profile at run time for a given PID. Another option would be to use systemd. However, I am mindful that it's not available everywhere just yet (but soon will be I hear) I am also aware, I might get a biased answer here :) Does anyone have any suggestions or projects that lead by example that Tracker could/should follow? Orthogonal to all of this, is another idea I had, which is to completely pause Tracker when the user is present (keyboard/mouse use) to avoid wasting cycles on stuff the user doesn't care about - a bit like how chat clients know when you're away or not. Maybe we should do both? Thoughts? Thanks, forgive the cross-list post. -- Regards, Martyn ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: fix cppcheck warnings
Minor patch. Fixes defects found by cppcheck: do not check if unsigned
value is const, reduce scope of a few variables.
Signed-off-by: Boris Egorov ego...@linux.com
---
src/shared/macro.h | 2 +-
src/shared/ring.c | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/shared/macro.h b/src/shared/macro.h
index 9ee332c..372475b 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -295,7 +295,7 @@ static inline size_t IOVEC_INCREMENT(struct iovec
*i, unsigned n, size_t k) {
for (j = 0; j n; j++) {
size_t sub;
-if (_unlikely_(k = 0))
+if (_unlikely_(k == 0))
break;
sub = MIN(i[j].iov_len, k);
diff --git a/src/shared/ring.c b/src/shared/ring.c
index 309075e..211d698 100644
--- a/src/shared/ring.c
+++ b/src/shared/ring.c
@@ -83,8 +83,6 @@ size_t ring_peek(Ring *r, struct iovec *vec) {
* return the number of bytes copied.
*/
size_t ring_copy(Ring *r, void *buf, size_t size) {
-size_t l;
-
assert(r);
assert(buf);
@@ -92,6 +90,8 @@ size_t ring_copy(Ring *r, void *buf, size_t size) {
size = r-used;
if (size 0) {
+size_t l;
+
l = r-size - r-start;
if (size = l) {
memcpy(buf, r-buf[r-start], size);
@@ -110,7 +110,6 @@ size_t ring_copy(Ring *r, void *buf, size_t size) {
*/
static int ring_resize(Ring *r, size_t nsize) {
uint8_t *buf;
-size_t l;
assert(r);
assert(nsize 0);
@@ -120,6 +119,8 @@ static int ring_resize(Ring *r, size_t nsize) {
return -ENOMEM;
if (r-used 0) {
+size_t l;
+
l = r-size - r-start;
if (r-used = l) {
memcpy(buf, r-buf[r-start], r-used);
--
2.1.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus-proxyd: improve compatibility with dbus-1
On 10/13/2014 03:29 PM, Lukasz Skalski wrote:
'GetConnectionUnixProcessID', 'GetConnectionUnixUser' and
'GetConnectionSELinuxSecurityContext' methods should return
'NameHasNoOwner' error (if chosen name is not available on bus)
with more detailed description - like dbus-1:
Could not get PID of name 'org.freedesktop.test': no such name.
Could not get UID of name 'org.freedesktop.test': no such name.
Could not get security context of name 'org.freedesktop.test': no such name.
Otherwise we have only laconic message without proper dbus error:
Error System.Error.ENXIO: No such device or address
Looks good to me.
Applied, thanks!
---
src/bus-proxyd/bus-proxyd.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index 52498f3..1bd7fee 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -643,27 +643,57 @@ static int process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m) {
return synthetic_reply_method_return(m, NULL);
} else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus,
GetConnectionSELinuxSecurityContext)) {
+const char *name;
_cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
+_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
-r = get_creds_by_message(a, m, SD_BUS_CREDS_SELINUX_CONTEXT,
creds, NULL);
+r = sd_bus_message_read(m, s, name);
+if (r 0)
+return r;
+
+r = get_creds_by_name(a, name, SD_BUS_CREDS_SELINUX_CONTEXT,
creds, NULL);
+if (r == -ESRCH || r == -ENXIO) {
+sd_bus_error_setf(error,
SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get security context of name '%s':
no such name., name);
+return synthetic_reply_method_errno(m, r, error);
+}
if (r 0)
return synthetic_reply_method_errno(m, r, NULL);
return synthetic_reply_method_return(m, y, creds-label,
strlen(creds-label));
} else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus,
GetConnectionUnixProcessID)) {
+const char *name;
_cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
+_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
-r = get_creds_by_message(a, m, SD_BUS_CREDS_PID, creds,
NULL);
+r = sd_bus_message_read(m, s, name);
+if (r 0)
+return r;
+
+r = get_creds_by_name(a, name, SD_BUS_CREDS_PID, creds,
NULL);
+if (r == -ESRCH || r == -ENXIO) {
+sd_bus_error_setf(error,
SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get PID of name '%s': no such
name., name);
+return synthetic_reply_method_errno(m, r, error);
+}
if (r 0)
return synthetic_reply_method_errno(m, r, NULL);
return synthetic_reply_method_return(m, u, (uint32_t)
creds-pid);
} else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus,
GetConnectionUnixUser)) {
+const char *name;
_cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
+_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
-r = get_creds_by_message(a, m, SD_BUS_CREDS_UID, creds,
NULL);
+r = sd_bus_message_read(m, s, name);
+if (r 0)
+return r;
+
+r = get_creds_by_name(a, name, SD_BUS_CREDS_UID, creds,
NULL);
+if (r == -ESRCH || r == -ENXIO) {
+sd_bus_error_setf(error,
SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get UID of name '%s': no such
name., name);
+return synthetic_reply_method_errno(m, r, error);
+}
if (r 0)
return synthetic_reply_method_errno(m, r, NULL);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: add edit verb
My general understanding is equal to dale. But with some consideration it led me to agree with the warning approach. Its no big deal setting EDITOR. Den 14/10/2014 01.06 skrev Ronny Chevalier chevalier.ro...@gmail.com: 2014-10-13 16:13 GMT+02:00 Simon McVittie simon.mcvit...@collabora.co.uk : On 13/10/14 14:38, Dale R. Worley wrote: My general understanding is that the traditional behavior when you need an editor but the user hasn't specified one is to use vi, and so people who don't want vi *always* set $VISUAL in their environment. The Right Thing™ is distro-specific. Debian and its derivatives have sensible-editor(1) which is a shell script that uses $VISUAL, $EDITOR, nano[1] or vi; I would expect systemd in Debian to use sensible-editor as its fallback, either via a configure option or a patch. In distros without sensible-editor, I'm tempted to say the solution is stop being a distro without sensible-editor. New systemd API? :-) Before I resend the patch, we should agree on what to do here, for me it makes more sense to raise an error asking to set either EDITOR or SYSTEMD_EDITOR than running vi or a sensible-editor like you said. Because, someone used to its editor will quit vi or sensible-editor and will try to find out how to set the editor for systemctl (Even if it is well known for EDITOR or VISUAL, some people don't set these variables). If we raise an error, someone not used to these variables but having a favorite editor will know how to change this. And if this person does not have a favorite editor and never used one (unlikely but I think this is the purpose of the sensible-editor ?), we can advice to set EDITOR to nano or an equivalent. ___ 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
[systemd-devel] [PATCH v3] tests: added tests for unit_file_get_{state, list}
This test constructs different unit file states and checks the output of unit_file_get_state and unit_file_get_list for each. This test characterizes the current output of the master branch in preparation for a patch which improves the performance of unit state detection in the face of thousands of units. --- .gitignore | 1 + Makefile.am| 44 ++- src/test/test-enabled.c| 141 + .../etc/systemd/system/masked.service | 1 + .../etc/systemd/system/maskedstatic.service| 1 + .../etc/systemd/system/some.target | 11 ++ .../system/some.target.wants/aliased.service | 1 + .../system/some.target.wants/also_masked.service | 1 + .../system/some.target.wants/another.service | 1 + .../system/some.target.wants/different.service | 1 + .../system/some.target.wants/masked.service| 1 + .../some.target.wants/templating@four.service | 1 + .../some.target.wants/templating@one.service | 1 + .../some.target.wants/templating@three.service | 1 + .../some.target.wants/templating@two.service | 1 + .../run/systemd/system/maskedruntime.service | 1 + .../run/systemd/system/maskedruntimestatic.service | 1 + .../run/systemd/system/other.target| 14 ++ .../system/other.target.wants/runtime.service | 1 + .../usr/lib/systemd/system/another.service | 9 ++ .../usr/lib/systemd/system/disabled.service| 9 ++ .../usr/lib/systemd/system/invalid.service | 1 + .../usr/lib/systemd/system/masked.service | 9 ++ .../usr/lib/systemd/system/maskedruntime.service | 9 ++ .../lib/systemd/system/maskedruntimestatic.service | 6 + .../usr/lib/systemd/system/maskedstatic.service| 6 + .../usr/lib/systemd/system/runtime.service | 9 ++ .../usr/lib/systemd/system/static.service | 6 + .../usr/lib/systemd/system/templating@.service | 9 ++ .../lib/systemd/system/templating@three.service| 9 ++ .../usr/lib/systemd/system/templating@two.service | 9 ++ .../usr/lib/systemd/system/unique.service | 9 ++ 32 files changed, 322 insertions(+), 3 deletions(-) create mode 100644 src/test/test-enabled.c create mode 12 test/test-enabled-root/etc/systemd/system/masked.service create mode 12 test/test-enabled-root/etc/systemd/system/maskedstatic.service create mode 100644 test/test-enabled-root/etc/systemd/system/some.target create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/aliased.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/also_masked.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/another.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/different.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/masked.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@four.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@one.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@three.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@two.service create mode 12 test/test-enabled-root/run/systemd/system/maskedruntime.service create mode 12 test/test-enabled-root/run/systemd/system/maskedruntimestatic.service create mode 100644 test/test-enabled-root/run/systemd/system/other.target create mode 12 test/test-enabled-root/run/systemd/system/other.target.wants/runtime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/another.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/disabled.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/invalid.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/masked.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedruntime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedruntimestatic.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedstatic.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/runtime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/static.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/templating@.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/templating@three.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/templating@two.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/unique.service diff --git
