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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
otherwise we end up with more than one job with the same identifier in
one run, causing some of them to get cancelled unexpectedly.
A quick follow-up to 85bd394df5.
Follow-up for 7d85383edb.
Apparently the previous limit set on the max number of inodes for /dev was too
small as a system with 4096 LUNs attached can consume up to 95k inodes for
symlinks:
# /bin/df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 49274377 95075 49179302 1% /dev
Hence this patch bumps the limit from 64k to 128k although the new limit is
still pretty arbitrary (that said, not sure if it really makes sense to put
such absolute limit number).
In 9cf75222f2 the conf.get() statements for `bpf-framework` and
`valgrind` were dropped, which causes the respective features to always
show as disabled (since they don't follow the "standard" naming scheme
with HAVE_/ENABLE_ prefixes).
This is a slightly modified version of the original
`cpp/uninitialized-local` CodeQL query which focuses only on variables
using the cleanup macros. Since this has proven to cause issues in the
past, let's panic on every uninitialized variable using any of the
cleanup macros (as long as they're written using the __cleanup__
attribute).
Some test results from a test I used when writing the query:
```
#define _cleanup_foo_ __attribute__((__cleanup__(foo)))
#define _cleanup_(x) __attribute__((__cleanup__(x)))
static inline void freep(void *p) {
*(void**)p = mfree(*(void**) p);
}
#define _cleanup_free_ _cleanup_(freep)
static inline void foo(char **p) {
if (*p)
*p = free(*p);
}
int main(void) {
__attribute__((__cleanup__(foo))) char *a;
char *b;
_cleanup_foo_ char *c;
char **d;
_cleanup_free_ char *e;
int r;
r = fun(&e);
if (r < 0)
return 1;
puts(a);
puts(b);
puts(c);
puts(*d);
puts(e);
return 0;
}
```
```
+| test.c:23:14:23:14 | e | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:20:26:20:26 | e | e |
+| test.c:27:10:27:10 | a | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:16:45:16:45 | a | a |
+| test.c:29:10:29:10 | c | The variable $@ may not be initialized here, but has a cleanup handler. | test.c:18:25:18:25 | c | c |
```
Get the cgroup root path from the current PID, so that when
ran by the user manager we can get to the right path.
Eg: foo.slice:10% will check under:
/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/foo.slice/cpu.pressure
Follow-up for 81513b382b
It could work, but it doesn't make much sense. If we already have openssl as
the cryptolib that provides the necessary support, let's not bring in another
library. Disallowing this simplifies things and reduces our support matrix.
This makes
- drop peers_with_unresolved_endpoint and peers_with_failed_endpoint,
- drop destroy handler for sd_resolve_query, and manage each query by peer,
- add random fluctuation to the timeout for retry handler,
- retry timer event source is now managed by peer,
- use sd_event_source_disable_unref().
When parse_ip_port() is directly used in a conf parser, then that's
fine, as the rvalue is already truncated.
When parse_ip_port() is used when e.g. parsing IP address with port,
then we should really refuse white space after colon.
Support for BPF might not have been checked, since it's not necessary
in test mode (eg: running offline analysis of units). This causes an
assert:
Assertion '(_error) != 0' failed at src/core/bpf-firewall.c:914, function emit_bpf_firewall_warning(). Aborting.
Export SYSTEMD_LOG_LEVEl=debug in TEST-65-ANALYZE is enough to trigger
this assert while doing an offline analysis of a unit that has some
firewall/network restrictions set.
Skip the warning if the manager is in test mode.
to suppress OpenSSL 3.0 deprecation warnings (until a proper solution is
deployed): RSA_free, EC_KEY_free, RSA_set0_key, RSA_size, EVP_PKEY_assign,
EC_KEY_set_group, and others are deprecated.
This allows resolved and importd to be built without libgcrypt.
Note that we now say either 'cryptographic library' or 'cryptolib'.
Co-authored-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
