IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
and let's emit a more comprehensive warning when an unsafe transition is
encountered.
Before this patch:
Unsafe symlinks encountered in /run/nrpe, refusing.
After:
Detected unsafe path transition / → /run during canonicalization of /run/nrpe.
We previously returned -EPERM but it can be returned for various other reasons
too.
Let's use -ENOLINK instead as this value shouldn't be used currently. This
allows users of CHASE_SAFE to detect without any ambiguities when unsafe
transitions are encountered by chase_symlinks().
All current users of CHASE_SAFE that explicitly reacted on -EPERM have been
converted to react on -ENOLINK.
When using networkd we currently have no way of ensuring that static
neighbor entries are set when our link comes up. This change adds a new
section to the network definition that allows multiple static neighbors
to be set on a link.
This allows us to convey that we are performing multiple link
configuration changes in parallel. This is needed to support configuring
neighbors while simultaneously configuring addresses and routes.
This will be useful to assert that our static route configuration always
happens after address configuration once our individual configure state
goes away.
Fixes the following error:
Failed to mount test /run: No such file or directory
By the time command "./test-udev check" calls function "fake_filesystems",
directory "test/run" must be present.
When there is a failure to setup the environment, the following happens:
1. Command "./test-udev check" exits with non-zero code.
2. Perl function "system" returns the code.
3. The code is evaluated as true by Perl.
Then we stop the test.
Turns out some tests like `test-execute` are tightly coupled with
systemd as PID1 (which should be fixed of course). In the meantime,
let's see how it goes.
Patches are shown on github with a fixed width (no matter how wide the window
is). When line numbers are high (we have some files with 5 digit line numbers),
the diff does not fit, and horizontal scrolling must be used when viewing the
patch. This is super annoying. Let's reduce the width a bit. I think 109 is
still very wide, but at least the github issue should be alleviated.
Much like for the mount units we need fields such as the slice
initialized by the time we activate the swap, hence when the kernel
let's us know about a new swap that appeared we need to initialize the
slice in any Swap object we allocated for that right-away, even if we
can't read the real unit file for the swap device.
For services (and other units) we generally follow the rule that at the
beginning of each cycle, i.e. when the INACTIVE/FAILED state is left for
ACTIVATING/ACTIVE we flush out various state variables. Mount units
handled this differently so far when the unit state change was effected
outside of systemd: in that case these variables would be flushed out
when going back to INACTIVE/FAILED already.
Let's fix that, and flush out this state always during the activating
transition, not during the deactivating transition.
We never know what the changes triggered by mount_set_state() do to the
unit. Let's be safe and copy the device path into our set, so that we
are safe against that.
It doesn't matter what kind of precise failure we had earlier with
loading the unit, let's report that it loaded successfully now, after
all the kernel is an OK source for that, like any other.
Whenever we notice a change on an existing /proc/self/mountinfo line,
let's update the deps generated from it. For that, let's flush out the
old deps generated this way, and add in the new ones.
This takes benefit of the fact that today (unlike a comment this patch
removes says) we can remove deps in a somewhat reasonable way.
Let's set 'from_proc_self_mountinfo' right away, since we know its from
there. This is important so that when the load queue is dispatched (and
thus mount_load() called) this
fact is already known.
In a previous commit we added logic that mount_add_extras() (or more
precisely mount_add_default_dependencies()) adds in dependencies on
remote-fs.target and local-fs.target, hence we can drop this from
mount_setup_new_unit() and let the usual load queue dispatching take
care of this.
