User records have the realname/gecos fields, groups never had that, but
it would really be useful to have it, hence let's add it with similar
semantics.
We enforce the same syntax as for GECOS, since it's better to start with
strict rules and losen them later instead of the opposite.
The commit 1070d271fa which was supposed
too fix this does not seem to take effect any more. We get again 34%
compilation success rate while scanning systemd itself. Moreover, the
installed header file breaks compilation of programs that include it:
"/usr/include/systemd/_sd-common.h", line 23: error #35: #error directive: "Do
not include _sd-common.h directly; it is a private header."
# error "Do not include _sd-common.h directly; it is a private header."
^
Follows the same pattern and features as RootImage, but allows an
arbitrary mount point under / to be specified by the user, and
multiple values - like BindPaths.
Original implementation by @topimiettinen at:
https://github.com/systemd/systemd/pull/14451
Reworked to use dissect's logic instead of bare libmount() calls
and other review comments.
Thanks Topi for the initial work to come up with and implement
this useful feature.
Given a string in the format 'one:two three four:five', returns a string
vector with each word. If the second element of the tuple is not
present, an empty string is returned in its place, so that the vector
can be processed in pairs.
[zjs: use EXTRACT_UNESCAPE_SEPARATORS instead of EXTRACT_CUNESCAPE_RELAX.
This way we do escaping exactly once and in normal strict mode.]
This code was changed in this pull request:
https://github.com/systemd/systemd/pull/16571
After some discussion and more investigation, we better understand
what's going on. So, update the comment, so things are more clear
to future readers.
From a report in https://bugzilla.redhat.com/show_bug.cgi?id=1861463:
usb-gadget.target: Failed to load configuration: No such file or directory
usb-gadget.target: Failed to load configuration: No such file or directory
usb-gadget.target: Trying to enqueue job usb-gadget.target/start/fail
usb-gadget.target: Failed to load configuration: No such file or directory
Assertion '!bus_error_is_dirty(e)' failed at src/libsystemd/sd-bus/bus-error.c:239, function bus_error_setfv(). Ignoring.
sys-devices-platform-soc-2100000.bus-2184000.usb-ci_hdrc.0-udc-ci_hdrc.0.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit usb-gadget.target not found.
I *think* this is the place where the reuse occurs: we call
bus_unit_validate_load_state(unit, e) twice in a row.
This allows more granular access control in PolicyKit rules, similar to
/etc/sudoers, for polkit actions:
* org.freedesktop.machine1.host-shell
* org.freedesktop.machine1.shell
Example configuration, place in /etc/polkit-1/rules.d/
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.machine1.host-shell"
&& subject.user == "my-user"
&& action.lookup("user") == "target-user") {
return polkit.Result.YES;
}
});
I happen to have a machine where /boot is not a separate mountpoint,
but rather just a directory under /. After upgrade to recent Fedora,
I found out that grub2 can't find any new kernels.
This happens because loadentry script generates kernel and initrd file
paths relative to /boot, while grub2 expects path to be relative to the
root of filesystem on which they are residing.
This commit fixes this issue by using stat's %m to find the mount point
of a partition holding the images, and using it as a prefix to be
removed from ENTRY_DIR_ABS.
Note that %m for stat requires coreutils 8.6, released in Oct 2010.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Apparently, if IO is still in flight at the moment we invoke LOOP_CLR_FD
it is likely simply dropped (probably because yanking physical storage,
such as a USB stick would drop it too). Let's protect ourselves against
that and always sync explicitly before we invoke it.
Fixed below systemd codesonar warning.
isprint() is invoked here with an argument of signed
type char, but only has defined behavior for int arguments that are
either representable as unsigned char or equal to the value
of macro EOF(-1).
As per codesonar report, in a number of libc implementations, isprint()
function implemented using lookup tables (arrays): passing in a
negative value can result in a read underrun.
The explicit limit is dropped, which means that we return to the kernel default
of 50% of RAM. See 362a55fc14 for a discussion why that is not as much as it
seems. It turns out various applications need more space in /dev/shm and we
would break them by imposing a low limit.
While at it, rename the define and use a single macro for various tmpfs mounts.
We don't really care what the purpose of the given tmpfs is, so it seems
reasonable to use a single macro.
This effectively reverts part of 7d85383edb. Fixes#16617.
The new retry intervals are [15, 20, 26, 34, 45, 60, 80, 106, 141, 188, 250,
333, 360, ...]. This should allow graceful response if a transient network
failure is encountered. Growth is exponential, but with a small power and
capped to a non-too-large value so that we resynchronize within a few minutes
after network is restored. I made the minimum 15 s to make sure that we never
send packets more often than that.
Fixes#16492.
Allows to specify mount options for RootImage.
In case of multi-partition images, the partition number can be prefixed
followed by colon. Eg:
RootImageOptions=1:ro,dev 2:nosuid nodev
In absence of a partition number, 0 is assumed.
This should be enough to fix https://bugzilla.redhat.com/show_bug.cgi?id=1856514.
But the limit should be significantly higher than 10% anyway. By setting a
limit on /tmp at 10% we'll break many reasonable use cases, even though the
machine would deal fine with a much larger fraction devoted to /tmp.
(In the first version of this patch I made it 25% with the comment that
"Even 25% might be too low.". The kernel default is 50%, and we have been using
that seemingly without trouble since https://fedoraproject.org/wiki/Features/tmp-on-tmpfs.
So let's just make it 50% again.)
See 7d85383edb.
(Another consideration is that we learned from from the whole initiative with
zram in Fedora that a reasonable size for zram is 0.5-1.5 of RAM, and that pretty
much all systems benefit from having zram or zswap enabled. Thus it is reasonable
to assume that it'll become widely used. Taking the usual compression effectiveness
of 0.2 into account, machines have effective memory available of between
1.0 - 0.2*0.5 + 0.5 = 1.4 (for zram sized to 0.5 of RAM) and
1.0 - 0.2*1.5 + 1.5 = 2.2 (for zram 1.5 sized to 1.5 of RAM) times RAM size.
This means that the 10% was really like 7-4% of effective memory.)
A comment is added to mount-util.h to clarify that tmp.mount is separate.