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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
So far we had various ad hoc APIs to query search paths:
systemd-analyze unit-paths, lookup_paths_log(), the pkgconfig file,
debug logs emitted by systemd-analyze cat-config.
But answering a simple question "what is the search path for tmpfiles,
sysusers, .network files, ..." is surprisingly hard.
I think we should have an api that makes it easy to query this. Pkgconfig is
not bad, but it is primarily a development tool, so it's not available in many
context. Also it can't provide support for paths which are influenced by
environment variables, and I'd like to be able to answer the question "what is
the search path for ..., assuming that VAR_FOO=... is set?".
Extending sd-path to support more of our internal paths seems to be most
flexible solution. We already have systemd-path which provides a nice
way to query, and we can add stuff like optional descriptions later on.
We we essentially get a nice programmatic and commmandline apis for the price
of one.
The two functions were duplicating a lot of functionality and more
importantly, they both had explicit lists of types which are search
paths. I want to add more types, and I don't want to have to remember
to add them to both lists.
When a new page is added using man/update-man-rules, ninja doesn't know
about the new target until a build is initiated, so build/man/man and
build/man/html would fail. Force a trivial build to regenerate the rules
before calling 'ninja -t'.
I think the two names were both pretty bad. They did not give a proper hint
what the difference between the two functions is, and sd_path_home sounds like
it is somehow related to /home or home directories or whatever, when in fact
both functions return the same set of paths as either a colon-delimited string
or a strv. "_strv" suffix is used by various functions in sd-bus, so let's
reuse that.
Those functions are not public yet, so let's rename.
The names with multiple lowercase words run together are hard to read. We
started that way with very short names like rootprefix, but then same pattern
was applied to longer and longer names. Looking at the body of .pc files
available on my machine, many packages use underscores; let's do the same. Old
names are kept for compatiblity, so this is backwards compatible.
In 1a29610f5f the change inadvertedly
disabled names with digit as the first character. This follow-up change
allows a digit as the first character in compat mode.
Fixes: #15141
When there are hundreds of mounts on the server, it will take a long
time to analyze the failure of a certain mount unit. So it is useful
to print the reason why unit_add_name() failed.
Add a simple check on the number of unit files that were found: return
`-ENOENT` when none is found from the function and thus `systemctl`
consequently exits with `1` (`EXIT_FAILURE`) if none were found.
Verification:
```bash
root@image:~# systemctl list-unit-files dbus-nonexistant.service; echo
$?
UNIT FILE STATE VENDOR PRESET
0 unit files listed.
1
root@image:~# systemctl list-unit-files dbus.service; echo $?
UNIT FILE STATE VENDOR PRESET
dbus.service static enabled
1 unit files listed.
0
```
Fixes#15082.
A common pattern in the codebase is reading a cgroup memory value
and converting it to a uint64_t. Let's make it a helper and refactor a
few places to use it so it's more concise.
Commit 08c588d18b moved attachment of the
sd-event into creation of the dhcp_client or ipv4ll in dhcp4_configure()
or ipv4ll_configure(), but these can also be created in link_load(),
so that creation needs to also perform sd-event attachment.
Without this, dhcp_client or ipv4ll created in link_load() will not have
an ->event and will fail assertion, causing networkd to fail, e.g.:
Assertion 'client->event' failed at src/libsystemd-network/sd-dhcp-client.c:1283, function client_start_delayed(). Ignoring.
ens2: Could not acquire DHCPv4 lease: Invalid argument
ens2: Failed
This may be not a popular setup, but in case kexec resides somewhere different
than the default location for KEXEC (`/usr/sbin/kexec`), don't just reboot and
try doing `reboot(RB_KEXEC)` instead, just like what `kexec -e` normally does.
```
❯ build/networkctl status veth99 ─╯
● 17: veth99
Link File: /usr/lib/systemd/network/99-default.link
Network File: /usr/lib/systemd/network/veth99.network
Type: ether
State: routable (configured)
Driver: veth
HW Address: 1e:04:f8:b8:2f:d4
MTU: 1500 (min: 68, max: 65535)
QDisc: noqueue
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 1/1
Auto negotiation: no
Speed: 10Gbps
Duplex: full
Port: tp
Address: 192.168.5.35 (DHCP4)
fe80::1c04:f8ff:feb8:2fd4
Gateway: 192.168.5.1
DNS: 192.168.5.1
NTP: 192.168.5.1
SIP: 192.168.5.4
192.168.5.5
Time Zone: Europe/Berlin
Mar 21 23:26:32 Zeus systemd-networkd[671]: veth99: Link DOWN
Mar 21 23:26:32 Zeus systemd-networkd[671]: veth99: Lost carrier
Mar 22 10:25:35 Zeus systemd-networkd[671]: veth99: Link UP
Mar 22 10:25:35 Zeus systemd-networkd[671]: veth99: Gained carrier
Mar 22 10:25:36 Zeus systemd-networkd[671]: veth99: Gained IPv6LL
Mar 22 10:29:02 Zeus systemd-networkd[671]: veth99: Link DOWN
Mar 22 10:29:02 Zeus systemd-networkd[671]: veth99: Lost carrier
Mar 22 10:29:13 Zeus systemd-networkd[671]: veth99: Link UP
Mar 22 10:29:13 Zeus systemd-networkd[671]: veth99: Gained carrier
Mar 22 10:29:14 Zeus systemd-networkd[671]: veth99: Gained IPv6LL
```