Jonathan Liu schrieb:
> On 27 April 2015 at 00:55, Kai Krakow wrote:
>> I've successfully created a Gentoo container on top of a Gentoo host. I
>> can start the container with machinectl, as I can with "systemctl start
>> ...".
>>
>> Inside the container (logged in via SSH), I could issue a rebo
On 27 April 2015 at 00:55, Kai Krakow wrote:
> I've successfully created a Gentoo container on top of a Gentoo host. I can
> start the container with machinectl, as I can with "systemctl start ...".
>
> Inside the container (logged in via SSH), I could issue a reboot command.
> But that just resul
Hello!
I've created a container with systemd-nspawn, "machinectl enable"d it, then
added machines.target to my default target (systemctl enable
machines.target) so that containers will be autostarted on boot. That works
so far.
But I discovered that systemd-networkd no longer configures my nor
On Fri, Apr 24, 2015 at 12:36 AM, Mantas Mikulėnas wrote:
> On Thu, Apr 23, 2015 at 6:25 PM, Lennart Poettering
> wrote:
>>
>> The kernel doesn't have any nice userspace APIs to translate PIDs like
>> this, to my knowledge at least.
>>
>> That said, one can implement something like this by using
static void free_sysvstub_hashmapp(Hashmap **h) {
while ((stub = hashmap_steal_first(*h)))
_cleanup_ sends a pointer to the pointer. and then this dereferences
that, which is kinda confusing, but yeah the code is correct, it would
be clearer with DEFINE_TRIVIAL_CLEANUP_FUNC()
On Sun, Ap
On Sun, Apr 26, 2015 at 8:31 PM, Thomas H.P. Andersen wrote:
> On Sun, Apr 26, 2015 at 8:23 PM, Shawn Landden wrote:
>> Actually you missed that free_sysvstub_hashmap does not tolerate NULL
>> pointers.
> Indeed. I will commit that.
Wait. free_sysvstub_hashmapp does tolerate NULL pointers.
has
Hello,
I have some remote journal from vps. It has come with
systemd-journal{-remote,-upload}.
```
$ ls -l /var/log/journal/remote/
remote-10.8.0.2@b9e0664324d845afa9e8a4f9c17db0c8-0001-000513ba70b17fc3.journal
remote-10.8.0.2@b9e0664324d845afa9e8a4f9c17db0c8-00d0-000513b
On Sun, Apr 26, 2015 at 8:23 PM, Shawn Landden wrote:
> Actually you missed that free_sysvstub_hashmap does not tolerate NULL
> pointers.
Indeed. I will commit that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedes
On 04/26/2015 07:40 PM, Kai Krakow wrote:
Sylvain Pasche schrieb:
I was looking for the instructions on how to enable a systemd-nspawn
container on boot in the systemd-nspawn documentation.
I saw that the example containing the "systemctl enable
systemd-nspawn@CONTAINER.service" command was r
Actually you missed that free_sysvstub_hashmap does not tolerate NULL pointers.
On Sun, Apr 26, 2015 at 11:21 AM, Shawn Landden wrote:
> On Sun, Apr 26, 2015 at 11:15 AM, Thomas H.P. Andersen
> wrote:
>> Hi Shawn,
>>
>> I fixed this a few hours ago. I also updated the status in coverity.
>> Is
On Sun, Apr 26, 2015 at 7:58 PM, Shawn Landden wrote:
> (coverity)
> ---
> src/shared/path-util.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/shared/path-util.c b/src/shared/path-util.c
> index 925bb28..95bfafc 100644
> --- a/src/shared/path-util.c
> +++ b/src/sha
On Sun, Apr 26, 2015 at 11:15 AM, Thomas H.P. Andersen wrote:
> Hi Shawn,
>
> I fixed this a few hours ago. I also updated the status in coverity.
> Is there something else I can do to avoid duplicated work?
I wasn't checking coverity, just reading the emails, so the duplicated
work in on my end.
(coverity)
v2
---
src/sysv-generator/sysv-generator.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
index 5ecd750..f56d727 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator
Hi Shawn,
I fixed this a few hours ago. I also updated the status in coverity.
Is there something else I can do to avoid duplicated work?
On Sun, Apr 26, 2015 at 7:58 PM, Shawn Landden wrote:
> (coverity)
> ---
> src/sysv-generator/sysv-generator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
(coverity)
---
src/shared/path-util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/path-util.c b/src/shared/path-util.c
index 925bb28..95bfafc 100644
--- a/src/shared/path-util.c
+++ b/src/shared/path-util.c
@@ -627,7 +627,7 @@ fallback_fstat:
a.st_in
(coverity)
---
src/sysv-generator/sysv-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c
b/src/sysv-generator/sysv-generator.c
index 5ecd750..714ce8f 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-ge
Sylvain Pasche schrieb:
> I was looking for the instructions on how to enable a systemd-nspawn
> container on boot in the systemd-nspawn documentation.
>
> I saw that the example containing the "systemctl enable
> systemd-nspawn@CONTAINER.service" command was removed in:
>
> commit e0ea94c1e2ab
Hi,
I was looking for the instructions on how to enable a systemd-nspawn
container on boot in the systemd-nspawn documentation.
I saw that the example containing the "systemctl enable
systemd-nspawn@CONTAINER.service" command was removed in:
commit e0ea94c1e2ab3930c85c6057189a2a829a13a800
A
Hello!
I've successfully created a Gentoo container on top of a Gentoo host. I can
start the container with machinectl. I can also login using SSH. So mission
almost accomblished (it should become a template for easy vserver cloning).
But from within the IPv6-capable container I cannot access t
Hello!
I've successfully created a Gentoo container on top of a Gentoo host. I can
start the container with machinectl, as I can with "systemctl start ...".
Inside the container (logged in via SSH), I could issue a reboot command.
But that just results in the container being shutdown. It never
Maybe syslog will do the trick?
BTW:
Do I need a syslog daemon to receive messages on UDP 514, or is/will be
systemd-journal-remote able to handle this? Didn't found a clue about
that in the man-page.
___
systemd-devel mailing list
systemd-devel@lists.
Excerpts from Lennart Poettering's message of 2015-04-24 16:40:07 +0200:
> > Hmm, I'm pretty sure the default StandardOutput=journal means stdout
> > will be a socket connection to journald, doesn't it?
>
> Ah, true!
>
> > (And since it's a process-specific thing, "echo "asdf" > /dev/stdout"
> >
> What happens if you use "dd" to write to /dev/stdout? Does that work,
> too? (i think that bash handles /dev/stderr specially when you use it
> with redirection, that's why I am asking).
I modified the unit file to use dd instead of nginx. I can reproduce the issue.
By mistake I forgot to add th
23 matches
Mail list logo
