Re: [systemd-devel] No error even a Required= service does not exist
25.11.2019 16:19, Mantas Mikulėnas пишет: On Mon, Nov 25, 2019 at 3:13 PM Jörg Weinhardt wrote: Hi, the behavior of systemd is not quite clear to me: I have a service which requires another service to be started and running, so I use a Requires= dependency to the required service. But if the required service does not exist at all, there is no error message from systemd. e.g. Requires=xyz.service produces no complaint and starts the service even if there is no xyz.service Is this the normal behavior or can I configure systemd to throw an error in this case? The docs say you can get this behavior if you also have After=xyz.service. (Not entirely sure why.) Because systemd dependencies are about jobs, not about units. "B Requires A" does not mean "unit B should not be active without A being active". All that it means - "when submitting start job for B also submit start job for A and fail start job for B if start job for A failed previously". Without After both start jobs are submitted concurrently; there is nothing to check when B is being started (as start job for A is not complete at this point) so there is no reason to fail start job for B. Which was the reason to invent BindTo in the first place - as poor man simulation of what everyone thinks Requires does (while it does not do it). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd 244 released
🎆 A new, official systemd release has just 🎉 been 🎊 tagged 🍾. Please download
the tarball here:
https://github.com/systemd/systemd/archive/v244.tar.gz
Changes since the previous release:
* Support for the cpuset cgroups v2 controller has been added.
Processes may be restricted to specific CPUs using the new
AllowedCPUs= setting, and to specific memory NUMA nodes using the new
AllowedMemoryNodes= setting.
* The signal used in restart jobs (as opposed to e.g. stop jobs) may
now be configured using a new RestartKillSignal= settting. This
allows units which signals to request termination to implement
different behaviour when stopping in preparation for a restart.
* "systemctl clean" may now be used also for socket, mount, and swap
units.
* systemd will also read configuration options from the EFI variable
SystemdOptions. This may be used to configure systemd behaviour when
modifying the kernel command line is inconvenient, but configuration
on disk is read too late, for example for the options related to
cgroup hierarchy setup. 'bootctl systemd-efi-options' may be used to
set the EFI variable.
* systemd will now disable printk ratelimits in early boot. This should
allow us to capture more logs from the early boot phase where normal
storage is not available and the kernel ring buffer is used for
logging. Configuration on the kernel command line has higher priority
and overrides the systemd setting.
systemd programs which log to /dev/kmsg directly use internal
ratelimits to prevent runaway logging. (Normally this is only used
during early boot, so in practice this change has very little
effect.)
* Unit files now support top level dropin directories of the form
.d/ (e.g. service.d/) that may be used to add configuration
that affects all corresponding unit files.
* systemctl gained support for 'stop --job-mode=triggering' which will
stop the specified unit and any units which could trigger it.
* Unit status display now includes units triggering and triggered by
the unit being shown.
* The RuntimeMaxSec= setting is now supported by scopes, not just
.service units. This is particularly useful for PAM sessions which
create a scope unit for the user login. systemd.runtime_max_sec=
setting may used with the pam_systemd module to limit the duration
of the PAM session, for example for time-limited logins.
* A new @pkey system call group is now defined to make it easier to
whitelist memory protection syscalls for containers and services
which need to use them.
* systemd-udevd: removed the 30s timeout for killing stale workers on
exit. systemd-udevd now waits for workers to finish. The hard-coded
exit timeout of 30s was too short for some large installations, where
driver initialization could be prematurely interrupted during initrd
processing if the root file system had been mounted and init was
preparing to switch root. If udevd is run without systemd and workers
are hanging while udevd receives an exit signal, udevd will now exit
when udev.event_timeout is reached for the last hanging worker. With
systemd, the exit timeout can additionally be configured using
TimeoutStopSec= in systemd-udevd.service.
* udev now provides a program (fido_id) that identifies FIDO CTAP1
("U2F")/CTAP2 security tokens based on the usage declared in their
report and descriptor and outputs suitable environment variables.
This replaces the externally maintained whitelists of all known
security tokens that were used previously.
* Automatically generated autosuspend udev rules for whitelisted
devices have been imported from the Chromium OS project. This should
improve power saving with many more devices.
* udev gained a new "CONST{key}=value" setting that allows matching
against system-wide constants without forking a helper binary.
Currently "arch" and "virt" keys are supported.
* udev now opens CDROMs in non-exclusive mode when querying their
capabilities. This should fix issues where other programs trying to
use the CDROM cannot gain access to it, but carries a risk of
interfering with programs writing to the disk, if they did not open
the device in exclusive mode as they should.
* systemd-networkd does not create a default route for IPv4 link local
addressing anymore. The creation of the route was unexpected and was
breaking routing in various cases, but people who rely
Re: [systemd-devel] How to apply for partition type GUID for Linux /boot?
On Fr, 29.11.19 10:52, Arseny Maslennikov (a...@cs.msu.ru) wrote: > On Thu, Nov 28, 2019 at 04:11:22PM +0100, Lennart Poettering wrote: > > On Do, 28.11.19 17:10, Arseny Maslennikov (a...@cs.msu.ru) wrote: > > > > > > This extended boot loader partition as GPT type UUID > > > > bc13c2ff-59e6-4262-a352-b275fd6f7172 and that's documented in the > > > > systemd-gpt-auto-generator(8) man page. > > > > > > The spec at freedesktop.org[1], (naturally) being the first Google hit > > > for "discoverable partitions spec" and also being referred to from a lot > > > of places all over the community[2][3][4][5][6], has no mention of the > > > extended boot loader partition. > > > > It's out of date. We should update it, incorporating the definitions > > from this spec: > > > > https://systemd.io/BOOT_LOADER_SPECIFICATION > > That would be awesome, I agree. > The parts of BLS that Paul mentioned in this thread can then just > refer to the DiscPartSpec instead of repeating it. > > There are disadvantages to dropping the fd.org wiki page, though. > In order of least controversial first: > * It looks like the page is already in Markdown (see below). > This would mean the wiki page requires no additional burden to > maintain: whenever a non-pre release is made, it can be automatically > updated from source. This makes sense given that the DiscPartSpec > development/discussion process de facto already takes place in the > systemd community's resources, while the spec is still technically a > freedesktop spec (has a wider scope than the systemd project, i. e. > can be implemented or adhered to outside of the systemd project; > Android as a rather heavy GPT user already does that). Hmm? You are saying Android cares for the GPT partition types in the discoverable partitions spec? Are you sure? > The domain name points to CloudFlare addresses; if the website is > indeed proxied by CloudFlare, it's easy to turn IPv6 on in their > control panel, and they automatically use IPv6 for new customers. > If systemd.io is implemented with GitHub Pages directly, that's a > bummer, we're at the mercy of GitHub network ops then. Actually, we we host this on GitHub pages precisely so that we don't have to actually maintain it... > wiki.freedesktop.org, on the other hand, works flawlessly over IPv6 > for a long time already. > * (no bad vibes intended) Public image concerns: > DiscPartSpec goes out of scope for the systemd project and is more > about the use of the hardware platform (system storage, to be exact) > to interoperate with external tools. It is much closer to util-linux > components, disk restore/backup tools, bootloaders. Yes, util-linux recognizes the GPT partition types we defined, but are you sure anyone cares outside of systemd-based distros? Besides that, even systemd-hating distros also adopted /etc/os-release, even though it's a systemd thing: https://www.freedesktop.org/software/systemd/man/os-release.html So people have apparently been ablet to overlook systemd affinity in that case, not sure why they shouldn't in the discoverable partitions spec case... (And there are similar cases, e.g. /run is a systemd thing. AFAIU not even systemd-hating distros still do /var/run) > To reinforce this point, this part of the community has great total > influence on the user base: they spread word of mouth and often write > primer blog posts / take notes, guides and tutorials for beginners, > Wikipedia pages, make decisions in the development of functionally > adjacent software that interoperates with us. I am sorry, but that's futile. Hater's gonna hate. I don't really think we should care anymore. Besides, any true systemd hater is also an fdo hater, no? so what's won? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
