On Di, 02.04.24 19:44, Petr Menšík (pemensik@xxxxxxxxxx) wrote:
> Function pid_notify_with_fds_internal from
> ./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, as
> suggested. Should I ask why, if not necessary?
The version in sd-daemon.c is a bit more complex because it supports a
few things typically not necessary:
- In systemd we support sd_notify() also via AF_VSOCK. i.e. PID 1 will
send sd_notify() messages itself to a supervisor VMM or similar, to
inform it when the system is booted up. It uses the very same protocol
as we usually use via AF_UNIX, but over AF_VSOCK. Support for
AF_VSOCK should be completely unnecessary for anyone but systemd
(i.e. PID1) itself, hence we didn't add it to the copy/paste version
version. The AF_VSOCK thing is awesome btw, because it allows you to
properly schedule activation of a bunch of VMs in order, with
correct waiting until they are ready to respond.
- The code allows overriding the sender struct ucred (i.e. the
SCM_CREDS control message te service manager will see). This exists
to implement the "systemd-notify" tool, which is always going to the
be a child process of the shell script it is invoked off, and which
wants to patch the sender PID hence to its own PPID. Nothing should
need that except of that tool.
- The code allows sending along fds to the service manager, to make
use of the "fdstore" concept in systemd (i.e. the service manager
can keep copies of a service's active fds in escrow, so that the
service can implement seamless restrats without losing any
resources).
So yes, most folks won#t need any of these three things, hence the
copy version of the code doesn't mention it.
> I think they preferred having fast fix over having long-term sustainable
> solution. I haven't seen offer to provide libsystemd-notify library with
> minimal dependencies, which they kindly refused. They preferred bundled code
> over systemd bloat in comment #13. I haven't seen bloat-less library
> considered in the bug, but might have missed it?
uff, "bloat", "bloat", "bloat".
I mean, libsystemd in git main doesn't pull in the compression libs
anymore, it doesnt pull in gcrypt either. It pulls in libc and libcap
only. Do you have a problem with these libraries?
Or are you concerned about the extra space in memory? Well, libsystemd
is going to be in memory anyway, you might as well use it. After all,
if Linux is smart enough to load it into memory only once, and just
give each consumer their own immutable memory map. Or in other words,
having yet another shared lib in the mix just makes things worse: more
of the same code, not less...
The way I see it, there are two options from my systemd perspective:
1. Use libsystemd.so, it doesn't pull in any other deps anymore
(except for libc and libcap), and is installed everywhere anyway.
Use this when:
- Your project is in C
- You don't care about an extra dep
- You use the other stuff libsystemd offers anyway (i.e. sd-bus,
sd-event or so)
1. Roll your own sd_notify(). [In case you hack is a C project: you can start
with the copylib the man pages now include
(i.e. https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes)
and adjust it to your framework of choice, coding style and so
on. i.e. adjust the error handling, logging to your choice.]
Use this when:
- Your project is not in C or
- You really don't want an extra dep
Lennart
--
Lennart Poettering, Berlin
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
