Hi,
>> I think /dev is the safest at the moment. Arguably it's wrong as it's
>> not an actual device node, but it's the only directory that lxc already
>> requires all distros not to mess with (or we wouldn't have working
>> console, tty, ...).
>
> What are some other alternatives?
>
> We could
Quoting Stéphane Graber (stgra...@ubuntu.com):
> On 12-09-19 10:12 AM, Christian Seiler wrote:
> > Hi,
> >
> >>> - is now in /run instead of /dev
> >>
> >> I don't think that part's going to work... Most distros mount /run as
> >> tmpfs at boot time which will hide anything you're putting in the
On 12-09-19 10:12 AM, Christian Seiler wrote:
> Hi,
>
>>> - is now in /run instead of /dev
>>
>> I don't think that part's going to work... Most distros mount /run as
>> tmpfs at boot time which will hide anything you're putting in there
>> before boot.
>
> Hmmm, that is indeed a problem... Do
Hi,
>> - is now in /run instead of /dev
>
> I don't think that part's going to work... Most distros mount /run as
> tmpfs at boot time which will hide anything you're putting in there
> before boot.
Hmmm, that is indeed a problem... Do you have any suggestions? Or
should we just keep it in /dev
On 12-09-19 07:49 AM, Christian Seiler wrote:
> Hi there,
>
> I've now updated my patch, there are now the following changes,
> partially based on feedback from this list, partially from sorting
> things in my head a bit.
>
> - socket instead of a FIFO
> - is now in /run instead of /dev
I do
Hi there,
I've now updated my patch, there are now the following changes,
partially based on feedback from this list, partially from sorting
things in my head a bit.
- socket instead of a FIFO
- is now in /run instead of /dev
- parent directories of socket inside container are automatically
Hi,
> It is a bit weird to bind mount this fifo.
IMHO, a lot of low-level stuff appears to be at first glance, until you
understand the reasoning behind it. Bind-mounting non-directories is
actually used a lot in namepsaces. For example, if you want to keep a
network namespace around after the
On 09/13/2012 05:22 PM, Christian Seiler wrote:
> This patch adds a simple notification system that allows the container to
> notify the host (in particular, the lxc-start process) that the boot process
> has been completed successfully. It also adds an additional status BOOTING
> that lxc-info may
Quoting Christian Seiler (christ...@iwakd.de):
> This patch adds a simple notification system that allows the container to
> notify the host (in particular, the lxc-start process) that the boot process
> has been completed successfully. It also adds an additional status BOOTING
> that lxc-info may
> I must admit the details aren't worked out, but the rough idea was
> something like the following. On the host have a directory per
> container, in which the socket is setup
>
>/var/lib/systemd/container/
>
> And bind '/var/lib/systemd/containerXXX' into the container in some
> location,
On Fri, Sep 14, 2012 at 12:12:57PM +0100, Christian Seiler wrote:
> >>If we want to have a back-channel, we'd need a socket, which
> >>makes just
> >>doing echo RUNNING > /dev/lxc-notify impossible, you'd need a
> >>special
> >>program for that. Having the template scripts dump an additional
> >>sc
> I'm very pleased about the discussion and efforts to implement such a
> feature because I already have asked for it in former times. In the
> one hand, this fifo approach may be used for more than the current
> task. But in the other hand, it's seems to need a bunch of
> dependencies.
You mean t
>> If we want to have a back-channel, we'd need a socket, which makes
>> just
>> doing echo RUNNING > /dev/lxc-notify impossible, you'd need a
>> special
>> program for that. Having the template scripts dump an additional
>> script
>> or upstart job or systemd unit file or whatever in the contai
On Thu, Sep 13, 2012 at 11:26:39PM +0200, Christian Seiler wrote:
> > I like the idea but haven't looked at the implementation yet as the
> > patch is really quite large. Quickly scanning through I briefly noticed
> > that the copyright headers for the new files are wrong (refer to IBM and
> > Dani
On 12-09-13 05:26 PM, Christian Seiler wrote:
>> I like the idea but haven't looked at the implementation yet as the
>> patch is really quite large. Quickly scanning through I briefly noticed
>> that the copyright headers for the new files are wrong (refer to IBM and
>> Daniel instead of Christian)
> I like the idea but haven't looked at the implementation yet as the
> patch is really quite large. Quickly scanning through I briefly noticed
> that the copyright headers for the new files are wrong (refer to IBM and
> Daniel instead of Christian).
I just copy&pasted them from the other files, m
On 12-09-13 03:18 PM, Serge Hallyn wrote:
> Quoting Christian Seiler (christ...@iwakd.de):
>> This patch adds a simple notification system that allows the container to
>> notify the host (in particular, the lxc-start process) that the boot process
>> has been completed successfully. It also adds an
Quoting Christian Seiler (christ...@iwakd.de):
> This patch adds a simple notification system that allows the container to
> notify the host (in particular, the lxc-start process) that the boot process
> has been completed successfully. It also adds an additional status BOOTING
> that lxc-info may
This patch adds a simple notification system that allows the container to
notify the host (in particular, the lxc-start process) that the boot process
has been completed successfully. It also adds an additional status BOOTING
that lxc-info may return. This allows the administrator and scripts to
di
19 matches
Mail list logo
