this problem be worked
around without upgrading the host or downgrading the guest?
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
On 15 May 2015 at 07:31, Lennart Poettering lenn...@poettering.net wrote:
On Sun, 10.05.15 11:20, Felipe Sateler (fsate...@debian.org) wrote:
Hi,
I'm having a problem with a systemd-nspawn'ed container. The guest
journal will not start and thus I have no logs.
The host is a 215
On 15 May 2015 at 10:15, Lennart Poettering lenn...@poettering.net wrote:
On Fri, 15.05.15 10:10, Felipe Sateler (fsate...@debian.org) wrote:
You appear to be using a systemd version without seccomp compiled in,
hence you won't get the container behaviour described, and you need to
disable
is upped.
Why isn't WantedBy=remote-fs.target an option? This would make any auto
remote mount pull nfs-common, but if none is then it won't be started
(unless that part of local-fs doesn't apply to remote-fs).
--
Saludos,
Felipe Sateler
___
systemd-devel
On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote:
On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote:
On Mon, 27 Jul 2015 16:51:02 +0200, Lennart Poettering wrote:
Coming back to your original question, there are two options:
1) nfs-common becomes
On 27 July 2015 at 15:58, Lennart Poettering lenn...@poettering.net wrote:
On Mon, 27.07.15 15:37, Felipe Sateler (fsate...@debian.org) wrote:
On 27 July 2015 at 12:36, Lennart Poettering lenn...@poettering.net wrote:
On Mon, 27.07.15 15:19, Felipe Sateler (fsate...@debian.org) wrote
t; goes away.
Is there any update on the switch to nftables? v227 still uses iptables...
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
o load the tcp pulseaudio module, allow
connections from the container ip, and inject PULSE_SERVER envvar into
the container.
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
source would have to be somehow imported into the debian systemd source,
and then used to build the shipped binary (ie, not importing the binary
artifacts alone).
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop
On 27 April 2016 at 10:41, Daniel Mack <dan...@zonque.org> wrote:
> On 04/27/2016 12:29 AM, Felipe Sateler wrote:
>> On Tue, 26 Apr 2016 17:28:34 +0200, Daniel Mack wrote:
>>
>>> Hi Michael,
>>>
>>> On 04/15/2016 11:00 PM, Daniel Mack wrote:
like default.target is used by quite a few services though:
> https://codesearch.debian.net/search?q=WantedBy%3Ddefault.target
>
> If default.target is not supposed to be used, then this should be
> mentioned somewhere.
The user manager has a real default.target. Many (most?) of the units
listed above are user services.
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
NVAL. This is different from things it defines itself, such
as @ settings for SystemCallFilter.
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Thu, Apr 27, 2017 at 9:50 PM, Michael Chapman <m...@very.puzzling.org>
wrote:
> On Fri, 28 Apr 2017, Felipe Sateler wrote:
>
>> On Thu, 27 Apr 2017 15:53:51 +1000, Michael Chapman wrote:
>>
>> Hello all,
>>>
>>> At present, when s
e the whole point of the exercise was to have some.service start
earlier, and this implies that some.service will be stopped later, I deem
this scenario likely if what you propose were implemented.
--
Saludos,
Felipe Sateler
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
gt; synchronous rather than fire-and-forget and expect it to wait for a
> response from systemd.
If the launch-xenstore script starts a daemon and then exists: why not
make the unit Type=forking and thus forget about systemd-notify --ready ?
--
Saludos,
Felipe Sateler
__
15 matches
Mail list logo