On Thu, Mar 06, 2014 at 07:54:05PM +0100, Lennart Poettering wrote:
On Thu, 06.03.14 16:55, Dariusz Michaluk (d.micha...@samsung.com) wrote:
On 05.03.2014 19:16, Lennart Poettering wrote:
nspawn and libvirt-lxc mostly follow the same code paths and register
via machined... So it's
Hi,
I tried to optimize my embedded configuration but I stumbled over the following
problem:
Let's assume systemd identified 10 processes on 'dependency level 0'. They all
can/should be started first/immediately.
Since they cannot be started at the same time - they start sequential with some
---
units/systemd-hostnamed.service.in |2 +-
units/systemd-logind.service.in|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/units/systemd-hostnamed.service.in
b/units/systemd-hostnamed.service.in
index 3f5ef75..ac7d9b6 100644
---
On 07.03.2014 10:39, Daniel P. Berrange wrote:
Can someone file a bug against libvirt for this and we'll look at not doing
this.
https://bugzilla.redhat.com/show_bug.cgi?id=1073891
--
Dariusz Michaluk
Samsung RD Institute Poland
Samsung Electronics
d.micha...@samsung.com
What is it needed for?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Old versions of powerd will be using the initctl fifo to signal
state changes. To maintain backward compability systemd should
be interpreting these messages, too.
Signed-off-by: Hannes Reinecke h...@suse.de
---
src/initctl/initctl.c | 71 ++-
1
07.03.2014 at 14:27 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote:
What is it needed for?
To fix SMACK:
[8.715491] type=1400 audit(946708910.490:2): lsm=SMACK
fn=smack_inode_permission action=denied subject=System object=_
requested=w pid=2324 comm=systemd-logind dev=tmpfs
On Fri, Mar 07, 2014 at 02:41:07PM +0100, Maciej Wereski wrote:
07.03.2014 at 14:27 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote:
What is it needed for?
To fix SMACK:
[8.715491] type=1400 audit(946708910.490:2): lsm=SMACK
fn=smack_inode_permission action=denied subject=System
On 03/06/2014 03:40 AM, David Timothy Strauss wrote:
When is startup considered over? I'd like if it meant before the
WantedBy unit was started so this value still has use for arbitrary
startup.
Lennard suggested this idea.
On Thu, Mar 6, 2014 at 5:42 PM, David Timothy Strauss
da...@davidstrauss.net wrote:
On Thu, Mar 6, 2014 at 2:57 PM, David Farning dfarn...@gmail.com wrote:
Now my philosophical sticking point is how big pid1 should be to do
what it needs to do. Practically, I am trying to understand where
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something* it gains or looses the access to it gracefully (with or
without a
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something* it gains or looses the access to it gracefully (with or
without a
On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering
lenn...@poettering.net wrote:
Heya!
Since yesterday systemd in git can now discover root, /home, /srv and
swap partitions automatically based on GPT type GUIDs, thus making
/etc/fstab unnecessary for simple setups.
I have now put together
Dear list,
Being a systemd dummie, I have a problem. It's a about running a
service as a user, which needs to synchronize with a systemd service.
Since the service needs to be part of the session, I presume that a
/systemd/user service isn't really the way to go (?): This leaves me
with the
On Fri, Mar 07, 2014 at 07:46:44PM +0100, Lukasz Pawelczyk wrote:
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something*
On Fri, 07.03.14 19:45, Lukasz Pawelczyk (hav...@gmail.com) wrote:
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an open file descriptor to some /dev/node and depending on
*something*
On Fri, 07.03.14 20:47, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering
lenn...@poettering.net wrote:
Heya!
Since yesterday systemd in git can now discover root, /home, /srv and
swap partitions automatically based on GPT type GUIDs, thus
On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:
Dear list,
Being a systemd dummie, I have a problem. It's a about running a
service as a user, which needs to synchronize with a systemd service.
What do you mean by synchronize?
Since the service needs to be part of the
Sorry for not being clear. The priob
On 3/7/14, Lennart Poettering lenn...@poettering.net wrote:
On Fri, 07.03.14 19:58, Alec Leamas (leamas.a...@gmail.com) wrote:
Dear list,
Being a systemd dummie, I have a problem. It's a about running a
service as a user, which needs to synchronize with
On 7 Mar 2014, at 20:09, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Mar 07, 2014 at 07:46:44PM +0100, Lukasz Pawelczyk wrote:
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that has an
On 7 Mar 2014, at 20:24, Lennart Poettering mzerq...@0pointer.de wrote:
On Fri, 07.03.14 19:45, Lukasz Pawelczyk (hav...@gmail.com) wrote:
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an application
that
On Fri, Mar 07, 2014 at 09:45:28PM +0100, Lukasz Pawelczyk wrote:
On 7 Mar 2014, at 20:09, Greg KH gre...@linuxfoundation.org wrote:
On Fri, Mar 07, 2014 at 07:46:44PM +0100, Lukasz Pawelczyk wrote:
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device
On Fri, 07.03.14 21:51, Lukasz Pawelczyk (hav...@gmail.com) wrote:
Problem:
Has anyone thought about a mechanism to limit/remove an access to a
device during an application runtime? Meaning we have an
application that has an open file descriptor to some /dev/node and
depending on
В Fri, 7 Mar 2014 20:37:12 +0100
Lennart Poettering lenn...@poettering.net пишет:
On Fri, 07.03.14 20:47, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering
lenn...@poettering.net wrote:
Heya!
Since yesterday systemd in git can now
2014-03-08 1:37 GMT+06:00 Lennart Poettering lenn...@poettering.net:
And for the root disk we declare explicitly that installers may only
drop the root= param from the kernel cmdline if the OS is installed as
first root partition on the disk. Otherwise it *must* specify it to make
sure the
If eg. setcap is in /sbin and user is building as a normal user without
$PATH having /sbin, the build system
will default to /usr/sbin/setcap as it's defined in AC_PATH_PROG and
fail during the build with 'setcap: command not found'
For example, my $PATH as normal user:
$ echo $PATH
26 matches
Mail list logo
