In trying to track down a stupid linker bug, I noticed a bunch of
memset() calls that should be using memzero() to make it more "obvious"
that the options are correct (i.e. 0 is not the length, but the data to
set). So fix up all current calls to memset(foo, 0, length) to
memzero(foo, length).
--
On Thu, Jan 30, 2014 at 05:15:27PM -0800, Michael Marineau wrote:
> ---
> src/tmpfiles/tmpfiles.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index bff9527..ae74af9 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfile
---
src/tmpfiles/tmpfiles.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index bff9527..ae74af9 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1509,6 +1509,7 @@ finish:
hashmap_free(globs);
strv_fr
On Thu, Jan 30, 2014 at 04:29:14PM -0500, Dan Walsh wrote:
> If I want to run a container as a service, it would be nice if it used the
> service
> cgroup configuration
Your patch will break the integration with machienctl, etc.
Would instead assigning the slice with --slice be enough?
Zbyszek
_
This seems applicable to what I'm working on (SaaS/PaaS company), but
I'm not sure I understand the distinction in capability this change
makes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listin
If I want to run a container as a service, it would be nice if it used the
service
cgroup configuration
---
src/nspawn/nspawn.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 1394ee6..9042412 100644
--- a/src/
This patch adds to new options:
-Z PROCESS_LABEL
This specifies the process label to run on processes run within the container.
-L FILE_LABEL
The file label to assign to memory file systems created within the container.
For example if you wanted to wrap an container with SELinux sandbox labels
On Thu, 30.01.14 20:23, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> Hello!
>
> Is it intentional that even with KillUserProcesses=no,
> user@.service is stopped as soon as the last user's session ends?
>
> And, in any case, is it possible to avoid that?
>
> To avoid XY problem: I'm trying t
On Thursday 30 January 2014 at 17:36:29, Lennart wrote:
> On Thu, 30.01.14 20:23, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> > Hello!
> >
> > Is it intentional that even with KillUserProcesses=no,
> > user@.service is stopped as soon as the last user's session ends?
> >
> > And, in any case,
Hello!
Is it intentional that even with KillUserProcesses=no,
user@.service is stopped as soon as the last user's session ends?
And, in any case, is it possible to avoid that?
To avoid XY problem: I'm trying to run a global per-user tmux server
inside the systemd user instance.
Thanks,
--
Iva
This is now part of libsystemd.
---
src/journal/libsystemd-journal.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/journal/libsystemd-journal.pc.in
b/src/journal/libsystemd-journal.pc.in
index 9883595..8418aaa 100644
--- a/src/journal/libsystemd-journal.pc.in
+++ b/s
Hi list,
On Wed, Jan 22, 2014 at 10:24:24AM +0100, Djalal Harouni wrote:
> On Thu, Jan 16, 2014 at 11:19:08AM +0100, Djalal Harouni wrote:
> > On Thu, Jan 16, 2014 at 06:01:58AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > Indeed, in a container (without your patches), sessions remain in
> > >
On 2013-06-25 17:47, Michael Biebl wrote:
Am 25.06.2013 13:13, schrieb Harald Jenny:
Dear Michael Biebl,
following the systemd survey and discussion I think these mails might
be
of interest to you concerning possible ways to solve the current issue
(not only in Debian but also SuSE/upstream i
13 matches
Mail list logo
