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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Apart from tests, the new argument isn't used anywhere, so there should be no
functional change. Note that the two arms of the big conditional are switched, so the
diff is artificially inflated. The actual code change is rather small. I dropped the
path which extracts ret_value manually, because it wasn't supporting unescaping of the
escape character properly.
It's useful to be able to combine a regular /usr/ file system with a
tmpfs as root, for an OS that boots up in volatile mode on every single
boot. Let's add explicit support for this via root=tmpfs.
Note the relationship to the existing systemd.volatile= option:
1. The kernel command line "root=/dev/… systemd.volatile=yes" will mount
the specified root fs, and then hide everything at the top by
overmounting it with a tmpfs, except for the /usr subtree.
2. The kernel command line "root=tmpfs mount.usr=/dev/…" otoh will mount
a toot fs at the top (just like the case above), but will then mount
the top-level dir of the fs specified in mount.usr= directly below
it.
Or to say this differently: in the first case /usr/ from the physical
storage fs is going to become /usr/ of the hierarchy ultimately booted,
while in the second case / from the physical storage fs is going to
become /usr of the hierarchy booted.
Philosophically I figure systemd.volatile= is more an option for
"one-off" boots, while root=tmpfs is something to have as default mode
of operation for suitable images.
This is currently hard to test reasonably, since Dracut refuses to
accept root=tmpfs. This needs to be addressed separately though.
If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.
But this unlikely to do the right thing and is inconsistent with what's done
for network mounts.
Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the
dependencies against the network requested by "_netdev" are (correctly) applied
to the mount unit only and the automount unit remains ordered against
local-fs.target.
The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.
Note: in general explicit deps specified via mount options should be used with
care and should be used to specify dependencies on other mount units only as it
can easily create ordering cycles otherwise like it's been seen in
https://github.com/systemd/systemd-stable/issues/69. Mount units (as well as
automount ones) are ordered before local-fs.target by default which is a
low-level target that most other units depend on.
Limit size of various tmpfs mounts to 10% of RAM, except volatile root and /var
to 25%. Another exception is made for /dev (also /devs for PrivateDevices) and
/sys/fs/cgroup since no (or very few) regular files are expected to be used.
In addition, since directories, symbolic links, device specials and xattrs are
not counted towards the size= limit, number of inodes is also limited
correspondingly: 4MB size translates to 1k of inodes (assuming 4k each), 10% of
RAM (using 16GB of RAM as baseline) translates to 400k and 25% to 1M inodes.
Because nr_inodes option can't use ratios like size option, there's an
unfortunate side effect that with small memory systems the limit may be on the
too large side. Also, on an extremely small device with only 256MB of RAM, 10%
of RAM for /run may not be enough for re-exec of PID1 because 16MB of free
space is required.
First After=local-fs-pre.target wasn't described in the man page although it's
part of the default dependencies automatically set by pid1.
Secondly, Before=local-fs.target was only set if the automount unit was
generated from the fstab-generator because the dep was explicitly
generated. It was also not documented as a default dependency.
Fix it by managing the dep from pid1 instead.
fstab-generator was also handling the default ordering dependencies for mount
units setup in initrd. To do that it was turning the defaults dependencies off
completely and ordered the mount unit against either local-fs.target or
initrd-fs.target or initrd-root-fs.target itself.
But it had the bad side effect to also remove all other default dependencies as
well. Thus if an initrd mount was using _netdev, the network dependencies were
missing.
In general fstab-generator shouldn't use DefaultDependecies=no because it can
handle only a small set of the default dependencies the rest are dealt by pid1.
So this patch makes pid1 handle all default dependencies.
Teaches systemd-fstab-generator these two unit options,
creating appropriate dependencies on the generated .mount
units. When used, they override any other automatically
generated dependencies, such as local-fs.target, and are
NOT suppressed by noauto. The new options are ignored for
/, in the same way that noauto is ignored.
Fixes: #14380
Signed-off-by: Antonio Russo <antonio.e.russo@gmail.com>
See https://bugzilla.redhat.com/show_bug.cgi?id=1763488: when we say that
'foo@*.service' is not a valid unit name, this is not clear enough. Let's
include the name of the operation that does not support globbing in the
error message:
$ build/systemctl enable 'foo@*.service'
Glob pattern passed to enable, but globs are not supported for this.
Invalid unit name "foo@*.service" escaped as "foo@\x2a.service".
...
chase_symlinks() would return negative on error, and either a non-negative status
or a non-negative fd when CHASE_OPEN was given. This made the interface quite
complicated, because dependning on the flags used, we would get two different
"types" of return object. Coverity was always confused by this, and flagged
every use of chase_symlinks() without CHASE_OPEN as a resource leak (because it
would this that an fd is returned). This patch uses a saparate output parameter,
so there is no confusion.
(I think it is OK to have functions which return either an error or an fd. It's
only returning *either* an fd or a non-fd that is confusing.)
When the .automount unit file already existed for any reason in the
`normal-dir` passed to `systemd-fstab-generator`, but the normal .mount unit
file did not, `f` was closed (but _not_ set to NULL). The call to
`generator_open_unit_file(..., automount_name, &f)` then failed because the
.mount unit file already existed. Now `f` did not point to an open FILE and the
later cleanup from the `_cleanup_fclose_` attribute failed with a double free.
Reset `f` to NULL before reusing it.
This is partially a refactoring, but also makes many more places use
unlocked operations implicitly, i.e. all users of fopen_temporary().
AFAICT, the uses are always for short-lived files which are not shared
externally, and are just used within the same context. Locking is not
necessary.
Otherwise we can end up with an ordering cycle. Since d54bab90, all
local mounts now gain a default `Before=local-fs.target` dependency.
This doesn't make sense for `/sysroot` mounts in the initrd though,
since those happen later in the boot process.
Closes: #12231
Instead of enabling it unconditionally and then using ConditionPathExists=/etc/fstab,
and possibly masking this condition if it should be enabled for auto gpt stuff,
just pull it in explicitly when required.
It would work when the generator was run by systemd, since generators
are always started in "/", but when running the generator for debugging
purposes the result would be ... different.
There should be no functional difference, except that the error message
is changd from "three or no arguments" to "zero or three arguments". Somehow
the inverted form always seemed strange.
umask() call is also dropped from run-generator. I think it wasn't dropped in
053254e3cb because the run generator was merged
around the same time.
Ideally, coccinelle would strip unnecessary braces too. But I do not see any
option in coccinelle for this, so instead, I edited the patch text using
search&replace to remove the braces. Unfortunately this is not fully automatic,
in particular it didn't deal well with if-else-if-else blocks and ifdefs, so
there is an increased likelikehood be some bugs in such spots.
I also removed part of the patch that coccinelle generated for udev, where we
returns -1 for failure. This should be fixed independently.
systemd already sets the umask (see e3b8d0637d). When
running under systemd, we don't need to set it. And when *not* running under
systemd, for example during development, there is no reason to override the user
config. Let's just drop those calls.
$ git grep -e 'umask\(' -l 'src/*generator*' |xargs perl -i -0pe 's|^[^\n]*umask\([^\n]+\n\n||gms'
