[systemd-devel] systemd-encrypt is a little painful

[Kai Hendry]

Hi guys,

After making https://www.youtube.com/watch?v=gh3jkIENmAM I'm thinking the 
install process could be a lot smoother if:

somehow systemd could do the initramfs, i.e. take over mkinitcpio's hook role

I don't understand why sd-encrypt can't autodiscover the cryto_LUKS root 
partition. Appending a line like:
options rw rd.luks.name=device-UUID=cryptroot root=/dev/mapper/cryptroot

is fraught with error and frustration!!


Furthermore if you get the above line wrong, the emergency systemd shell 
appears completely useless. There is the 1m30s timeout that I can never escape, 
and the emergency shell is confusing and not fit for purpose in the sense of 
correcting the /dev/mapper/cryptroot address.

If these should be new issues or perhaps they are issues already, then do let 
me know.
https://github.com/systemd/systemd/issues?q=sd-encrypt

Sidenote: would be cool if a basic en.network could be generated.

Perhaps this is all done already in Fedora? haha, I use Arch btw.

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

Re: [systemd-devel] Why systemd keeps references on passed sockets ?

[Francis Moreau]

On Sat, Sep 5, 2020 at 12:18 AM Lennart Poettering
 wrote:
>
> On Fr, 04.09.20 21:53, Francis Moreau (francis.m...@gmail.com) wrote:
>
> > Hi,
> >
> > I have a service which is activated by a socket unit. When systemd
> > passes the (netlink) socket to my service it seems that it still keeps
> > a reference on the socket, at least ss(8) showed this.
> >
> > Is this expected ? If yes can this be prevented ?
> >
> > I'm asking because my service may not need the socket in some cases
> > hence it closes it but systemd keeps it open and the socket keeps
> > receiving messages and consuming memory for nothing.
>
> It's how socket activation works really (at least with Accept=no): pid
> 1 allocate the socket and activates your service every time something
> happens on it, except if your service is already running. Thus a
> service can auto-start, process one or more events on it, can exit
> when idle, or even crash, it doesn't matter, no traffic is lost
> (except the very datagram it was processing or the connection that it
> was handling when it crashed), and as soon as POLLIN is seen on the
> socket again the service is started again can continue where it left
> off.
>
> You are apparently looking for a different model? i.e. where automatic
> restart and exit-on-idle do not exist? A model like that is currently
> not implemented. Can you elaborate on the usecase?
>

My service is listening several sockets (which are all pased by
systemd) but depending on user configuration my service may not need
to use all sockets and in this case it would be great if the sockets
not needed stop receiving messages and theirs resources are released.

 I tried to close the socket but nothing seems to happen.

Couldn't systemd react on the socket close and if the service still
runs then it closes the socket until it detects the service is stopped
?

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

Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

[Alexander E. Patrakov]

On Sat, Sep 5, 2020 at 3:12 AM Lennart Poettering
 wrote:
>
> On Fr, 04.09.20 21:41, Dave Howorth (syst...@howorth.org.uk) wrote:
>
> > On Fri, 4 Sep 2020 17:44:23 +0200
> > Lennart Poettering  wrote:
> > > On Fr, 04.09.20 17:10, Reindl Harald (h.rei...@thelounge.net) wrote:
> > >
> > > > > No, that's not supported in sd-boot. A boot loader is a boot
> > > > > loader, it should contain a fragile storage stack. It's kinda
> > > > > what sd-boot is supposed to do better than grub.
> > > >
> > > > well, a boot loader should just *load* and not write anything so
> > > > RAID1 is technically no problem and it shouldn't matter which of
> > > > the 1, 2, 3 or 4 disks is there unless one survived.
> > >
> > > Robust boot loaders typically want to write boot counters to disk, so
> > > that they can automatically revert back to older versions of the
> > > OS/kernel if it doesn't boot. Thus some form of write access is
> > > necessary if you care about robustness.
> >
> > But surely a boot loader of all things should never try to write to the
> > place it is loading from? Booting should be idempotent (as long as it
> > works, for sure). The only sane policy would seem to be that the loader
> > had another path to a separate writable area?
>
> UEFI provides file system access. Both read and write. Typically for
> VFAT. Yeah, a boot loader should not modify the files it is itself
> loaded from and also keep writes generally at a minimum, but counting
> boots is generally the absolute minimum necessary, and can be
> implemented by single sector updates in file systems such as VFAT. So
> that's what sd-boot for example does.

May I know why this design has been chosen over keeping the boot
counts in UEFI variables?

-- 
Alexander E. Patrakov
CV: http://pc.cd/PLz7
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] unsubscribe

[程 书意]

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

Re: [systemd-devel] non-existent unit instances

[Kevin P. Fleming]

On Sat, Sep 5, 2020 at 9:50 AM Michael Chapman  wrote:
> Since the instance name for this unit is used to derive a configuration
> filename, a simple solution here would be to use:
>
> ConditionPathExists=/etc/openvpn/client/%i.conf
>
> in the unit. Or, if you want the start job to fail when given a bad
> instance name:
>
> AssertPathExists=/etc/openvpn/client/%i.conf

Thanks for this tip, this is very useful! I have a number of service
units which launch scripts and those scripts will fail if their
configuration files are not present; it will be handy to have the
start job itself fail in this situation.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Online documentation doesn't show versions where a certain feature was introduced

[Tom Ryder]

On Fri, Sep 04, 2020 at 03:06:13PM +0200, Böszörményi Zoltán wrote:
Please take a page from the GLIB/GTK maintainers' notebook and indicate 
the version where a certain feature was introduced and all the versions 
where the same feature was gaining extensions or fixes.


I would also find this very helpful for doing portable configuration 
management between OS versions.  If the versions can't be listed inline 
in what are already somewhat verbose man pages, perhaps a separate 
feature version matrix could be maintained or generated?


For an example of what this could look like---if it doesn't already 
exist---the Bash Hackers Wiki maintains one for Bash to which I very 
often refer:




Something this useful would be great to show to the systemd-averse, who 
tend to cite instability of systemd's interface as a reason to reject 
it.  Similar portability tables like this are already a great start:




--
Tom Ryder 
Maybe we can bring back the light.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel