On 21.1.2020 18.11, Lennart Poettering wrote:
On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote:
i was already considering "hidepid" as the root cause
systemd-243.5-1.fc31.x86_64 other than
systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with
hidepid= is broken. We
Am 21.01.20 um 18:39 schrieb Lennart Poettering:
> On Di, 21.01.20 17:51, Reindl Harald (h.rei...@thelounge.net) wrote:
>
Either way, check if hidepid=0 makes things work for you
>>> well, it's not that easy because after change it from 2 to 1 the newly
>>> upgraed VM is *toast* meaing no
On Di, 21.01.20 17:51, Reindl Harald (h.rei...@thelounge.net) wrote:
> >> Either way, check if hidepid=0 makes things work for you
> > well, it's not that easy because after change it from 2 to 1 the newly
> > upgraed VM is *toast* meaing no network and even TTY login times out
> >
> > well, after
Am 21.01.20 um 17:19 schrieb Reindl Harald:
>
>
> Am 21.01.20 um 17:17 schrieb Lennart Poettering:
>> On Di, 21.01.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote:
>>
> i was already considering "hidepid" as the root cause
> systemd-243.5-1.fc31.x86_64 other than
> systemd-2
On Tue, Jan 21, 2020 at 05:08:14PM +0100, Lennart Poettering wrote:
> if you speciy the same user name its going to have the same uid.
>
> use something like this:
>
> ...
> [Service]
> ...
> User=foo-%i
> DynamicUser=1
> ...
>
> That way you have a separate user for each instance, and the user
Am 21.01.20 um 17:17 schrieb Lennart Poettering:
> On Di, 21.01.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote:
>
i was already considering "hidepid" as the root cause
systemd-243.5-1.fc31.x86_64 other than
systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with
>>>
On Di, 21.01.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote:
> >> i was already considering "hidepid" as the root cause
> >> systemd-243.5-1.fc31.x86_64 other than
> >> systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with
> >
> > hidepid= is broken. We don't support that, sorry. V
Am 21.01.20 um 17:11 schrieb Lennart Poettering:
> On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>> i was already considering "hidepid" as the root cause
>> systemd-243.5-1.fc31.x86_64 other than
>> systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with
>
> hide
Hi,
I am trying to sandbox processes that run via instantiated units and
the DynamicUser feature seems like a nice solution. However, when I start
several such units simultaneously, the dynamic UID, while random, is the same
for all instances (see below). Is this expected behavior and is t
On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote:
> i was already considering "hidepid" as the root cause
> systemd-243.5-1.fc31.x86_64 other than
> systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with
hidepid= is broken. We don't support that, sorry. Various component
On Di, 21.01.20 16:02, Leonid Isaev (leonid.is...@ifax.com) wrote:
> On Tue, Jan 21, 2020 at 03:53:10PM +, Leonid Isaev wrote:
> > I am trying to sandbox processes that run via instantiated units and
> > the DynamicUser feature seems like a nice solution. However, when I start
> > several
Am 21.01.20 um 16:58 schrieb Lennart Poettering:
> On Di, 21.01.20 16:17, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>>
>>
>> Am 21.01.20 um 16:13 schrieb Lennart Poettering:
>>> On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote:
>>>
Hi
about to upgrade pre
On Tue, Jan 21, 2020 at 03:53:10PM +, Leonid Isaev wrote:
> I am trying to sandbox processes that run via instantiated units and
> the DynamicUser feature seems like a nice solution. However, when I start
> several such units simultaneously, the dynamic UID, while random, is the same
> fo
On Di, 21.01.20 16:17, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>
> Am 21.01.20 um 16:13 schrieb Lennart Poettering:
> > On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote:
> >
> >> Hi
> >>
> >> about to upgrade prepare Fedora 31 upgrades
> >>
> >> -
Am 21.01.20 um 16:17 schrieb Reindl Harald:
>
>
> Am 21.01.20 um 16:13 schrieb Lennart Poettering:
>> On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote:
>>
>>> Hi
>>>
>>> about to upgrade prepare Fedora 31 upgrades
>>>
>>> --
>>>
>>> Jan 21 15:30:01
Am 21.01.20 um 16:13 schrieb Lennart Poettering:
> On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>> Hi
>>
>> about to upgrade prepare Fedora 31 upgrades
>>
>> --
>>
>> Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported
>>
On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote:
> Hi
>
> about to upgrade prepare Fedora 31 upgrades
>
> --
>
> Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported
> controllers: No such process
> Jan 21 15:30:01 testserver syst
Hi
about to upgrade prepare Fedora 31 upgrades
--
Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported
controllers: No such process
Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager
object: No such process
Jan 21 15:30:01 testse
On Tue, Jan 21, 2020 at 1:34 PM Pavla Kratochvilova
wrote:
> Hi,
>
> Is there any API for systemd-detect-virt that would provide a way to call
> it from a c++ code?
>
> I need to detect if running in container and "systemd-detect-virt -c" gets
> the job done, but I don't want to call the shell co
Hi,
Is there any API for systemd-detect-virt that would provide a way to call
it from a c++ code?
I need to detect if running in container and "systemd-detect-virt -c" gets
the job done, but I don't want to call the shell command. I haven't found
any good way, but maybe I am missing something.
T
20 matches
Mail list logo
