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... 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
l
---
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
--- a/units/systemd-hostnamed.servic
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 R&D 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
---
src/initctl/initctl.c | 71 ++-
1 file changed, 7
07.03.2014 at 14:27 Zbigniew Jędrzejewski-Szmek 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" ino=11023
[
On Fri, Mar 07, 2014 at 02:41:07PM +0100, Maciej Wereski wrote:
> 07.03.2014 at 14:27 Zbigniew Jędrzejewski-Szmek 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
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.
http://lists.freedesktop.org/archives/systemd-devel/2014-March/01
On Thu, Mar 6, 2014 at 5:42 PM, David Timothy Strauss
wrote:
> On Thu, Mar 6, 2014 at 2:57 PM, David Farning 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
>> those boundaries should be and how to
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 something like a spec describing the logic
behind that, and what it is good for:
http:/
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 notific
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 notific
On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering
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 something like a
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 probl
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
> *somethin
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
> *someth
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
> wrote:
> > Heya!
> >
> > Since yesterday systemd in git can now discover root, /home, /srv and
> > swap partitions automatically based on GPT type GUIDs, thus making
> > /
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
Sorry for not being clear. The priob
On 3/7/14, Lennart Poettering 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 a systemd ser
On 7 Mar 2014, at 20:09, Greg KH 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 open file descript
On 7 Mar 2014, at 20:24, Lennart Poettering 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 has an ope
On Fri, Mar 07, 2014 at 09:45:28PM +0100, Lukasz Pawelczyk wrote:
>
> On 7 Mar 2014, at 20:09, Greg KH 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 appli
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
> >> depen
В Fri, 7 Mar 2014 20:37:12 +0100
Lennart Poettering пишет:
> 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
> > wrote:
> > > Heya!
> > >
> > > Since yesterday systemd in git can now discover root, /home, /srv and
2014-03-08 1:37 GMT+06:00 Lennart Poettering :
> 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 right partition is fou
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
/usr/local/bi
27 matches
Mail list logo
