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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Currently there does not exist a way to specify a path relative to which
all binaries executed by Exec should be found. The only way is to
specify the absolute path.
This change implements the functionality to specify a path relative to which
binaries executed by Exec*= can be found.
Closes#6308
When we are in --user mode there's no point in doing PolicyKit/ask-pw
because both of these systems are only used by system-level services.
Let's disable the two agents for that automaticlly hence.
Prompted by: #20576
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
systemd-run is documented to as being able to connect and run on a
specific user bus with "--user --machine=lennart@.host" arguments.
This PR updates some logic that prevented this from working.
This reverts behaviour of systemd-run's unit name generation to the
status quo ante of #18871: we chop off the ":1." prefix if we can.
However, to address the issue that the unique name can overrun we then
do what #18871 did as fallback: only chop off the ":" prefix.
This way we should have pretty names that look like they always looked
in the common case, but in the case of a unique name overrun we still
will have names that work.
Follow-up for #18871
Some code in systemd-run checks that a bus's unique name must start with
`:1.`. However the dbus specification on unique connection names only specifies
that it must begin with a colon. And the freedesktop/dbus implementation allows
allows unique names to go up to `:INT_MAX.INT_MAX`. So update the
current check to only look for a colon at the beginning.
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
Like it's customary in our codebase bus_error_message() internally takes
abs() of the passed error anyway, hence no need to explicitly negate it.
We mostly got this right, but in too many cases we didn't. Fix that.
This is a fix-up for a7c71d214c: since we
now don't wait for the job to finish anymore right after enqueuing it,
we should not exit our ptyfwd logic before the unit is back to inactive
*and* no job pending anymore.
Otherwise we'd not read the services input while waiting for the job to
wait, and there's no point in waiting for the job anyway if we wait for
the unit to stop ultimately.
Fixes: #15395
This cleans up and unifies the outut of --help texts a bit:
1. Highlight the human friendly description string, not the command
line via ANSI sequences. Previously both this description string and
the brief command line summary was marked with the same ANSI
highlight sequence, but given we auto-page to less and less does not
honour multi-line highlights only the command line summary was
affectively highlighted. Rationale: for highlighting the description
instead of the command line: the command line summary is relatively
boring, and mostly the same for out tools, the description on the
other hand is pregnant, important and captions the whole thing and
hence deserves highlighting.
2. Always suffix "Options" with ":" in the help text
3. Rename "Flags" → "Options" in one case
4. Move commands to the top in a few cases
5. add coloring to many more help pages
6. Unify on COMMAND instead of {COMMAND} in the command line summary.
Some tools did it one way, others the other way. I am not sure what
precisely {} is supposed to mean, that uppercasing doesn't, hence
let's simplify and stick to the {}-less syntax
And minor other tweaks.
Fixes#13756. We were returning things that didn't make much sense:
we would always use the exit_code value as the exit code. But it sometimes
contains a exit code from the process, and sometimes the number of a signal
that was used to kill the process. We would also ignore SuccessExitStatus=
and in general whether systemd thinks the service exited successfully
(hence the issue in #13756, where systemd would return success/SIGTERM,
but we'd just look at the SIGTERM part.)
If we are doing --wait, let's always propagate the exit code/status from
the child.
While at it, make the documentation useful.
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".
...
When emitting the calendarspec warning we want to see some color.
Follow-up for 04220fda5c.
Exceptions:
- systemctl, because it has a lot hand-crafted coloring
- tmpfiles, sysusers, stdio-bridge, etc, because they are also used in
services and I'm not sure if this wouldn't mess up something.
When we determine that a calendar expression cannot elapse anymore,
print a warning but proceed regardless like we normally would.
Quite possibly a remote system has a different understanding of time
(timezone, system clock) than we have, hence we really shouldn't change
behaviour here client side, but log at best, and then leave the decision
what to do to the server side.
Follow-up for #12299
Services invoked by PID1 have $INVOCATION_ID initialized, hence let's do
that for scope units (where the payload process is invoked by us on the
client side) too, to minimize needless differences.
Fixes: #8082
I keep running "systemd-run -t /bin/bash" to quickly get a shell running
in service context. I suspect I am not the only one, hence let's add a
shortcut for it. While we are at it, let's make it smarter, and
automatically inherit the $SHELL of the invoking user as well as the
working directory, and let's imply --pty. --shell (or -S) is hence
equivalent to "-t -d $SHELL".
I find myself testing service management quite often with "systemd-run
-t /bin/bash". For that it is handy if the invoked shell would use the
working directory I am currently in. Hence introduce a shorthand for
that:
$ systemd-run -dt /bin/bash
This will automatically insert a WorkingDirectory= property into the
transient service, pointing to the working directory of the caller.
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.
