Hello all
I have the following socket unit:
[Unit]
Description=unix sock
[Socket]
ListenStream=@foo/%i
Backlog=128
Service=foo@%i.service
[Install]
[email protected]
Alias=sockets.target.wants/[email protected]
[email protected]
Alias=sockets.target.wants/[email protected]
[email protected]
Heya,
http://www.freedesktop.org/software/systemd/systemd-23.tar.bz2
Bigger changes:
- A new tool to handle binfmt_misc at boot. Just drop something into
/etc/binfmt.d to deal with wine, mono, and java. See binfmt.d(5).
- ConditionSecurity to run services only if SELinux is enabled/disabled
On Mon, Apr 4, 2011 at 23:39, Michal Schmidt wrote:
> On Mon, 4 Apr 2011 22:51:55 +0200 Kay Sievers wrote:
>> We really need something here that is not tied to the / inode, because
>> we want to support r/o / or / on tmpfs with only the subdirs mounted
>> from disk. xattrs of / just have the same
On Mon, 4 Apr 2011 22:51:55 +0200 Kay Sievers wrote:
> We really need something here that is not tied to the / inode, because
> we want to support r/o / or / on tmpfs with only the subdirs mounted
> from disk. xattrs of / just have the same issues as /.-files, it's
> just a different storage format
2011/4/4 Michal Schmidt :
> On Mon, 04 Apr 2011 20:59:58 +0200 Alexander Boström wrote:
>> > If on the other hand / stays read-only for the whole duration of
>> > working with SELinux disabled, then no contexts will be harmed and
>> > relabeling will not be necessary.
>>
>> If / is ro but /var is r
On Mon, 04 Apr 2011 20:59:58 +0200 Alexander Boström wrote:
> > If on the other hand / stays read-only for the whole duration of
> > working with SELinux disabled, then no contexts will be harmed and
> > relabeling will not be necessary.
>
> If / is ro but /var is rw then a relabel is still useful
sön 2011-04-03 klockan 21:39 +0200 skrev Michal Schmidt:
> If on the other hand / stays read-only for the whole duration of
> working with SELinux disabled, then no contexts will be harmed and
> relabeling will not be necessary.
If / is ro but /var is rw then a relabel is still useful, right?
An
Kay Sievers ([email protected]) said:
> This flag file is supposed to be found at the next bootup, right?
>
> Nothing specific about your patch, I know that's the status quo, but I
> guess we need some better place for such files as /, as we are aiming
> for a read-only root, or want to suppor
Hello
On Mon, Apr 4, 2011 at 6:01 PM, Albert Strasheim wrote:
> I'm trying to set up a configuration where a variable number of
> devices under /dev/mapper get automounted.
> I've started with the following:
> # cat mpath\@.mount
> [Unit]
> Description=Data File System
After reading the systemd.
On Mon, 04.04.11 16:59, Albert Strasheim ([email protected]) wrote:
>
> Hello
>
> On Mon, Apr 4, 2011 at 8:45 AM, Albert Strasheim wrote:
> > I was wondering if anyone had an example of a service unit that sets
> > up a chroot jail with RootDirectory= but also mounts /proc, /sys and
> > maybe a
On Mon, 04.04.11 08:45, Albert Strasheim ([email protected]) wrote:
> Hello all
>
> I was wondering if anyone had an example of a service unit that sets
> up a chroot jail with RootDirectory= but also mounts /proc, /sys and
> maybe a directory with some binaries and configuration inside it?
Ther
On Mon, 04.04.11 08:21, Albert Strasheim ([email protected]) wrote:
Heya,
> Is there a way to specify the equivalent of RLIM_INFINITY for LimitNOFILE,
> etc.?
>
> I did a quick grep of the systemd source, but couldn't find an obvious answer.
I have now modified systemd git to accept "infinity"
On Mon, 04.04.11 16:44, Albert Strasheim ([email protected]) wrote:
>
> Hello
>
> On Mon, Apr 4, 2011 at 4:32 PM, Lennart Poettering
> wrote:
> > On Mon, 04.04.11 07:13, Albert Strasheim ([email protected]) wrote:
> >> Hello all
> >> I just tried to start a socket unit with ListenStream=0 in th
Hello all
I'm trying to set up a configuration where a variable number of
devices under /dev/mapper get automounted.
I've started with the following:
# cat mpath\@.mount
[Unit]
Description=Data File System
[Mount]
What=/dev/mapper/%i
Where=/mnt/%i
Type=ext4
[Install]
[email protected]
Alia
Hello
On Mon, Apr 4, 2011 at 8:45 AM, Albert Strasheim wrote:
> I was wondering if anyone had an example of a service unit that sets
> up a chroot jail with RootDirectory= but also mounts /proc, /sys and
> maybe a directory with some binaries and configuration inside it?
It seems I could write a
Hello
On Mon, Apr 4, 2011 at 4:32 PM, Lennart Poettering
wrote:
> On Mon, 04.04.11 07:13, Albert Strasheim ([email protected]) wrote:
>> Hello all
>> I just tried to start a socket unit with ListenStream=0 in the
>> configuration, but this yields the following error:
>> Failed to issue method cal
On Mon, 04.04.11 15:08, Michal Schmidt ([email protected]) wrote:
> This should fix the crash reported by Dan Horak on s390x which
> does not have VTs.
Uh. Brown paper bag bug. Thanks for the patch. Applied.
Lennart
--
Lennart Poettering - Red Hat, Inc.
__
On Mon, 04.04.11 07:13, Albert Strasheim ([email protected]) wrote:
> Hello all
>
> I just tried to start a socket unit with ListenStream=0 in the
> configuration, but this yields the following error:
>
> Failed to issue method call: Unit zero.socket failed to load: Invalid
> argument. See syste
On Mon, 04.04.11 15:50, Florian Kriener ([email protected]) wrote:
>
> On Monday 04 April 2011 15:32:25 Lennart Poettering wrote:
> > > That makes sense. I'm just sad that I cannot try out systemd git
> > > outside of a systemd-nspawn container without breaking the
> > > installed version from
Lennart Poettering wrote:
> On Mon, 04.04.11 13:41, Ludwig Nussel ([email protected]) wrote:
>
> > > There are. A lot of software creates subdirectories beneath
> > > /var/lock, for example LVM. If you allow creation of lockfiles in
> > > /var/lock, then this enables the same programs to break
On Mon, Apr 4, 2011 at 15:50, Florian Kriener wrote:
> On Monday 04 April 2011 15:32:25 Lennart Poettering wrote:
>> > That makes sense. I'm just sad that I cannot try out systemd git
>> > outside of a systemd-nspawn container without breaking the
>> > installed version from the debian repositorie
On Monday 04 April 2011 15:32:25 Lennart Poettering wrote:
> > That makes sense. I'm just sad that I cannot try out systemd git
> > outside of a systemd-nspawn container without breaking the
> > installed version from the debian repositories.
>
> Hmm, why precisely?
>
> I use "make install" on my
On Mon, 04.04.11 15:08, Florian Kriener ([email protected]) wrote:
>
> On Monday 04 April 2011 02:47:43 Kay Sievers wrote:
> > > Are there plans to support other distributions like debian in
> > > upstream git wholeheartedly or will systemd git only run properly
> > > on fedora? Or am I lumping
On Mon, 04.04.11 13:41, Ludwig Nussel ([email protected]) wrote:
> > There are. A lot of software creates subdirectories beneath
> > /var/lock, for example LVM. If you allow creation of lockfiles in
> > /var/lock, then this enables the same programs to break LVM (and
> > everything else creati
This should fix the crash reported by Dan Horak on s390x which
does not have VTs.
---
src/manager.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/manager.c b/src/manager.c
index dae746c..9fc854b 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -127,7 +127,7 @@ sta
On Monday 04 April 2011 02:47:43 Kay Sievers wrote:
> > Are there plans to support other distributions like debian in
> > upstream git wholeheartedly or will systemd git only run properly
> > on fedora? Or am I lumping packaging and development together
> > here?
>
> It does run on many distros wi
Lennart Poettering wrote:
> On Mon, 04.04.11 10:56, Ludwig Nussel ([email protected]) wrote:
> > Lennart Poettering wrote:
> >
> > So as long as there are no inherently unsolvable problems
> > with lockdev using /var/lock directly I see no need to go the a half
> > solution /var/lock/lockdev.
On Mon, 04.04.11 10:56, Ludwig Nussel ([email protected]) wrote:
>
> Lennart Poettering wrote:
> > On Fri, 01.04.11 16:37, Ludwig Nussel ([email protected]) wrote:
> > > In any case declaring some directory as the standard place for lock
> > > files doesn't fully solve the problem anyways
Lennart Poettering wrote:
> On Fri, 01.04.11 16:37, Ludwig Nussel ([email protected]) wrote:
> > In any case declaring some directory as the standard place for lock
> > files doesn't fully solve the problem anyways. The exact lock file
> > naming isn't quite standardized either. There's at leas
29 matches
Mail list logo
