parse_path_argument() unconditionally makes the passed path absolute,
without handling '~' of any sort. I think this generally makes sense
in most tools, since ~ expansion is typically done by the shell
and we wouldn't be seeing them in the first place and hence special
casing is not worth it. But in run0 let's explicit enable '~'.
When switching to another user it's oftentimes desirable to also spawn
the target user's shell. sudo supports this via -i flag, run0 currently
doesn't. We don't want to proactively query NSS ourselves, since
that would fall short when operating remotely. Let's instead teach
the service manager to spawn the command using the user's default shell.
I opted for "|" instead of "." in the end because the latter seems
a bit obscure. But happy to change it to something else if a better option
comes up.
Otherwise, initrd-cleanup.service requests isolation thus the socket
is stopped before switching root, and several early events after
switching root may be lost.
As a test, it just increases our code coverage in a fake way.
When run manually, it can be used to conveniently print what logind
thinks about various processes:
$ build/test-sd-login
sd_pid_get_session(0) → No data available
sd_pid_get_unit(0) → user@1000.service
sd_pid_get_user_unit(0) → app-ghostty-transient-5088.scope
sd_pid_get_machine_name(0) → No such file or directory
sd_pid_get_slice(0) → user-1000.slice
sd_pid_get_user_slice(0) → app.slice
sd_pid_get_owner_uid(0) → 1000
sd_pid_get_cgroup(0) → /user.slice/user-1000.slice/user@1000.service/app.slice/app-ghostty-transient-5088.scope/surfaces/556FAF50BA40.scope
$ build/test-sd-login cgroup 1
sd_pid_get_cgroup(1) → /init.scope
The existing text grew organically as features were added and was
not very organized. Reorder it and break into paragraphs grouped
by topic. The description of the :errno syntax is replaced by a short
reference to the SystemCallErrorNumber= setting. This makes the
text shorter and makes it easier to explain how the two settings combine.
Passing in the func, file and line information complicates the
interface. On top of that, it prevents forward declaring Hashmap in
strv.h, as we need to pass the macros everywhere that we allocate a
hashmap, which means we have to include the hashmap header everywhere
we have a function that allocates a hashmap instead of just having to
forward declare Hashmap.
Let's drop the file, func and line information from the debug information.
Instead, in the future we can add a description field to hashmaps like we
already have in various other structs to describe the purpose of the hashmap
which should be much more useful than having the file, line and function where
the hashmap was allocated.