Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

2019-11-01 Thread Matthew Garrett
On Thu, Oct 31, 2019 at 5:06 PM Lennart Poettering
 wrote:
> Paging doesn't allow that really. It's always ugly. You'd have to have
> your own UI stack in the initrd, i.e. basically have an alternative
> root disk, that possesses the screen exclusively as long as the system
> is up but not unlocked yet.

The initrd already contains a UI stack in order to permit disk unlock
at boot time, so this really doesn't seem like a problem? Switch VTs
before suspend, suspend the LUKS devices so all access blocks and the
keys are dropped, suspend, resume, run the unlock codepath from
initramfs again, switch VTs back, we're good? Things are a little more
complicated if you want to use the disk unlock phrase to also trigger
desktop unlock, but everything else seems reasonably straightforward -
processes will sit in D state until unlocked, but time will continue
as expected.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd put it uinder a custom slice

2019-11-01 Thread Bhasker C V
On 01/11/2019 10:03, Lennart Poettering wrote:
> On Fr, 01.11.19 09:32, Bhasker C V (bhas...@unixindia.com) wrote:
>
>> I am really sorry but I am still not able to get this working with a
>> 'name' in slice. Is there a naming convention to be used for the name
>> passed-on to  --slice=. I could not understand this from the man
>> page.
> Slices in systemd are named .slice, following a similar
> scheme to all other unit types.
>
> i.e. use --slice=test.slice
Excellent ! that worked ! thanks
>
> Lennart
>
> --
> Lennart Poettering, Berlin


-- 
Bhasker C V
Secure Mails: http://keys.gnupg.net/pks/lookup?op=get&search=0x4D05FEEC54E47413
Registered Linux User: #306349 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd put it uinder a custom slice

2019-11-01 Thread Lennart Poettering
On Fr, 01.11.19 09:32, Bhasker C V (bhas...@unixindia.com) wrote:

> I am really sorry but I am still not able to get this working with a
> 'name' in slice. Is there a naming convention to be used for the name
> passed-on to  --slice=. I could not understand this from the man
> page.

Slices in systemd are named .slice, following a similar
scheme to all other unit types.

i.e. use --slice=test.slice

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd put it uinder a custom slice

2019-11-01 Thread Bhasker C V
On 01/11/2019 09:20, Lennart Poettering wrote:
> On Fr, 01.11.19 08:59, Bhasker C V (bhas...@unixindia.com) wrote:
>
>>> systemd owns the cgroup tree, only subtrees for which delegation is
>>> explicitly turned on can be managed by other programs, for example for
>>> the purpose of container managers.
>>>
>>> Thus, creating cgroups manually, directly via cgcreate at the top of
>>> the tree is explicitly not supported.
>>>
>>> Use systemd's own concepts, i.e. slice units, direct cgroup access
>>> bypassing systemd at the top of the tree is explicitly not supported.
>> a) Does this mean that running systemd-nspawn from command-line (via
>> scripts) does not give the user any control over cgroups ? if that is
>> possible please can you help explaning a bit more ?
> on cgroupsv1 nspawn delegates access to a subtree of the name=systemd
> hierarchy to its payload (i.e. none of the other controllers). This is
> the only thing that is relatively safe to do.
>
> on cgroupsv2 nspawn delegates access to a subtree of the full tree,
> including any controllers, as on cgroupsv2 controller delegation is
> finally safe.
>
>> b) What is the use of --slice= option in systemd-nspawn ? if I can pass
>> a slice name, I derive that it should be possible (by some means) to
>> create the slice name with some command ?
> You can specify any slice you want, systemd will start it as needed
> on behalf of the nspawn container.

I am really sorry but I am still not able to get this working with a
'name' in slice. Is there a naming convention to be used for the name
passed-on to  --slice=. I could not understand this from the man page.

$ sudo systemd-nspawn  -jbD ./a  --slice=test
Spawning container a on /tmp/a.
Press ^] three times within 1s to kill container.
Failed to register machine: Invalid unit name 'test'
Parent died too early$ sudo systemd-nspawn  -jbD ./a 
--slice=machine.slice/test
Spawning container a on /tmp/a.
Press ^] three times within 1s to kill container.
Failed to register machine: Invalid unit name 'machine.slice/test'
Parent died too early

$ systemd-nspawn --version
systemd 241 (241)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid

$ sudo systemd-nspawn  -jbD ./a  --slice=/machine.slice/test
Spawning container a on /tmp/a.
Press ^] three times within 1s to kill container.
Failed to register machine: Invalid unit name '/machine.slice/test'
Parent died too early$

>
> Key is: systemd owns the cgroup tree from the top, and delegation of
> subtrees is the only safe and supported way how other software can
> write to the cgroup tree, and then only in the subtree they got
> delegated.
>
> Lennart
>
> --
> Lennart Poettering, Berlin


-- 
Bhasker C V
Secure Mails: http://keys.gnupg.net/pks/lookup?op=get&search=0x4D05FEEC54E47413
Registered Linux User: #306349 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd put it uinder a custom slice

2019-11-01 Thread Lennart Poettering
On Fr, 01.11.19 08:59, Bhasker C V (bhas...@unixindia.com) wrote:

> > systemd owns the cgroup tree, only subtrees for which delegation is
> > explicitly turned on can be managed by other programs, for example for
> > the purpose of container managers.
> >
> > Thus, creating cgroups manually, directly via cgcreate at the top of
> > the tree is explicitly not supported.
> >
> > Use systemd's own concepts, i.e. slice units, direct cgroup access
> > bypassing systemd at the top of the tree is explicitly not supported.
>
> a) Does this mean that running systemd-nspawn from command-line (via
> scripts) does not give the user any control over cgroups ? if that is
> possible please can you help explaning a bit more ?

on cgroupsv1 nspawn delegates access to a subtree of the name=systemd
hierarchy to its payload (i.e. none of the other controllers). This is
the only thing that is relatively safe to do.

on cgroupsv2 nspawn delegates access to a subtree of the full tree,
including any controllers, as on cgroupsv2 controller delegation is
finally safe.

> b) What is the use of --slice= option in systemd-nspawn ? if I can pass
> a slice name, I derive that it should be possible (by some means) to
> create the slice name with some command ?

You can specify any slice you want, systemd will start it as needed
on behalf of the nspawn container.

Key is: systemd owns the cgroup tree from the top, and delegation of
subtrees is the only safe and supported way how other software can
write to the cgroup tree, and then only in the subtree they got
delegated.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev can fail to read stdout of processes spwaned in udev_event_spawn

2019-11-01 Thread Michal Sekletar
On Fri, Nov 1, 2019 at 1:49 AM Paul Davey
 wrote:

> What is the best way to fix this issue?  I have locally had success
> just calling the on_spawn_io callback in the process success branch of
> on_spawn_sigchld, but I am unsure if this is an acceptable fix.

In the callback, we call read() only once and I don't think we have
any guarantee that kernel will give us the entire output of the child
process in one go. I figure we should drain the file descriptor in a
loop.

Michal

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd put it uinder a custom slice

2019-11-01 Thread Bhasker C V

On 31/10/2019 11:02, Lennart Poettering wrote:
> On Mi, 30.10.19 11:08, Bhasker C V (bhas...@unixindia.com) wrote:
>
>> Hi all,
>>
>>  I have been googl-ing for a few days now but could not stumble upon a
>> solution I am looking for.
>>
>> Apologies if this is a noob question.
>>
>> Is there a way to use custom slices with my systemd-nspawn container ?
>>
>> I see that systemd-nspawn man page says using --slice= but any such
>> cgroup created is not accepted by this option (I dont know how to create
>> a slice externally from systemd unit-files)
>>
>> $ sudo cgcreate  -g freezer,memory:/test
> This is not supported.
>
> systemd owns the cgroup tree, only subtrees for which delegation is
> explicitly turned on can be managed by other programs, for example for
> the purpose of container managers.
>
> Thus, creating cgroups manually, directly via cgcreate at the top of
> the tree is explicitly not supported.
>
> Use systemd's own concepts, i.e. slice units, direct cgroup access
> bypassing systemd at the top of the tree is explicitly not supported.

a) Does this mean that running systemd-nspawn from command-line (via
scripts) does not give the user any control over cgroups ? if that is
possible please can you help explaning a bit more ?

b) What is the use of --slice= option in systemd-nspawn ? if I can pass
a slice name, I derive that it should be possible (by some means) to
create the slice name with some command ?

> Lennart
>
> --
> Lennart Poettering, Berlin

Bhasker C V
Secure Mails: http://keys.gnupg.net/pks/lookup?op=get&search=0x4D05FEEC54E47413
Registered Linux User: #306349 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel