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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
We would accept a message with 40k signature and spend a lot of time iterating
over the nested arrays. Let's just reject it early, as we do for !gvariant
messages.
This is modelled after the existing ERRNO_IS_RESOURCES() and in
particular ERRNO_IS_DISCONNECT(). It returns true for all transient
network errors that should be handled like EAGAIN whenever we call
accept() or accept4(). This is per documentation in the accept(2) man
page that explicitly says to do so in the its "RETURN VALUE" section.
The error list we cover is a bit more comprehensive, and based on
existing code of ours. For example EINTR is included too (since we need
that to cover cases where we call accept()/accept4() on a blocking
socket), and of course ERRNO_IS_DISCONNECT() is a bit more comprehensive
than the list in the man page too.
No technical reason, except that later on we want to add a new
ERRNO_IS() which uses the parameter twice and where we want to avoid
double evaluation, and where we'd like to keep things in the same style.
* Use more secure https://www.uefi.orghttp://www.uefi.org directs to https://uefi.org/, so this saves one
redirect.
$ curl -I http://www.uefi.org
HTTP/1.1 302 Found
Server: nginx
Date: Tue, 09 Apr 2019 14:54:46 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
X-Content-Type-Options: nosniff
Location: https://uefi.org/
Cache-Control: max-age=1209600
Expires: Tue, 23 Apr 2019 14:54:46 GMT
Run the command below to update all occurrences.
git grep -l http://www.uefi.org | xargs sed -i 's,http://www.uefi.org,https://www.uefi.org,'
* Use https://uefi.org to save redirect
Save one redirect by using the target location.
$ curl -I https://www.uefi.org
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 09 Apr 2019 14:55:42 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: keep-alive
X-Content-Type-Options: nosniff
Location: https://uefi.org/
Cache-Control: max-age=1209600
Expires: Tue, 23 Apr 2019 14:55:42 GMT
Run the command below to update all occurrences.
git grep -l https://www.uefi.org | xargs sed -i 's,https://www.uefi.org,https://uefi.org,'
This should PID collisions a tiny bit less likely, and thus improve
security and robustness.
2^22 isn't particularly a lot either, but it's the current kernel
limitation.
Bumping this limit was suggested by Linus himself:
https://lwn.net/ml/linux-kernel/CAHk-=wiZ40LVjnXSi9iHLE_-ZBsWFGCgdmNiYZUXn1-V5YBg2g@mail.gmail.com/
Let's experiment with this in systemd upstream first. Downstreams and
users can after all still comment this easily.
Besides compat concern the most often heard issue with such high PIDs is
usability, since they are potentially hard to type. I am not entirely sure though
whether 4194304 (as largest new PID) is that much worse to type or to
copy than 65563.
This should also simplify management of per system tasks limits as by
this move the sysctl /proc/sys/kernel/threads-max becomes the primary
knob to control how many processes to have in parallel.
This adds a new per-service OOMPolicy= (along with a global
DefaultOOMPolicy=) that controls what to do if a process of the service
is killed by the kernel's OOM killer. It has three different values:
"continue" (old behaviour), "stop" (terminate the service), "kill" (let
the kernel kill all the service's processes).
On top of that, track OOM killer events per unit: generate a per-unit
structured, recognizable log message when we see an OOM killer event,
and put the service in a failure state if an OOM killer event was seen
and the selected policy was not "continue". A new "result" is defined
for this case: "oom-kill".
All of this relies on new cgroupv2 kernel functionality: the
"memory.events" notification interface and the "memory.oom.group"
attribute (which makes the kernel kill all cgroup processes
automatically).
Let's rename the .cgroup_inotify_wd field of the Unit object to
.cgroup_control_inotify_wd. Let's similarly rename the hashmap
.cgroup_inotify_wd_unit of the Manager object to
.cgroup_control_inotify_wd_unit.
Why? As preparation for a later commit that allows us to watch the
"memory.events" cgroup attribute file in addition to the "cgroup.events"
file we already watch with the fields above. In that later commit we'll
add new fields "cgroup_memory_inotify_wd" to Unit and
"cgroup_memory_inotify_wd_unit" to Manager, that are used to watch these
other events file.
No change in behaviour. Just some renaming.
