summaryrefslogtreecommitdiffstats
path: root/src/run (follow)
Commit message (Collapse)AuthorAgeFilesLines
* run: do not pass the pty slave fd to transient service in a machineZbigniew Jędrzejewski-Szmek2024-06-061-17/+31
| | | | | | | | | | | | | | | | Follow-up for 28459ba1f4df824d5ef7f7d1a9acb6953ea24045 The pty path returned by OpenMachinePTY() cannot be opened from outside the machine, hence let's use the plain Standard{Input,Output,Error}=tty in such a case. This means if --machine= is specified, #32916 would occur. A comprehensive fix requires a new dbus method in machined, which shall be material for v257. See also: https://github.com/systemd/systemd/pull/33216#discussion_r1628020429 Replaces #33216 Co-authored-by: Mike Yuan <me@yhndnzj.com>
* run: also show a pretty string for main exit status, if anyMike Yuan2024-05-261-6/+7
| | | | This brings output on par with unit_log_process_exit().
* run: when disconnected from PTY forwarder, exit event loop if not --waitMike Yuan2024-05-211-3/+8
| | | | | | | | | | | | Follow-up for ade0789fabbf01b95bf54d32f8cab1217a753f03 The change in behavior was partly intentional, as I think if both --wait and --pty are used, manually disconnecting from PTY forwarder should not result in systemd-run exiting with "Finished with ..." log. But we should check for --wait here. Closes #32953
* run: pass the pty slave fd to transient serviceMike Yuan2024-05-191-3/+9
| | | | | | | | | | | | | | | | | The rationale is similar to 40e1f4ea7458a0a80eaf1ef356e52bfe0835412e. Currently, we only pass TTYPath=/dev/pts/... to the transient service spawned by systemd-run. This is a bit problematic though, when ExecStartPre= or ExecStopPost= is used. Since when these control processes get to run, the main process is not yet started/has already exited, hence the slave suffers from the same vhangup problem as the mentioned commit. By passing the slave fd in, the service manager will hold the fd open as long as the service is alive. Fixes #32916
* run: do not log "Error on PTY forwarding logic" when disconnected due to ↵Mike Yuan2024-05-191-2/+4
| | | | user operation
* nspawn, vmspawn, run0: add env var for turning off background tintingLennart Poettering2024-05-021-1/+1
| | | | | | | Some people are just sad, sad lost souls who don't like even the tiniest ray of color in their life. Let's add an env var knob for allowing them to turn the background tinting off, to drive the last bit of color from their life so that they can stay in their grey grey life.
* tree-wide: Use log_setup() everywhereDaan De Meyer2024-04-251-3/+1
| | | | | Otherwise the default log target is the console and we won't use the journal socket even if it is available.
* run/run: fix invocation ID handlingYu Watanabe2024-04-251-1/+1
| | | | Fixes a regression introduced by 8157cc0e3e33c97b406cc088cf001ca524154f64.
* run: query for SoftRebootsCount only for system scope runsLuca Boccassi2024-04-071-5/+10
| | | | | | | Only the system manager records soft reboots, and the user session is restarted anyway so it doesn't suffer from the ID clash issue Follow-up for ed358516937780b524a2cfa833427da3df1bc87f
* run: fix generated unit name clash after soft-rebootLuca Boccassi2024-03-281-3/+18
| | | | | | | | | | | | | | | | When sd-run connects to D-Bus rather than the private socket, it will generate the transient unit name using the bus ID assigned by the D-Bus broker/daemon. The issue is that this ID is only unique per D-Bus run, if the broker/daemon restarts it starts again from 1, and it's a simple incremental counter for each client. So if a transient unit run-u6.service starts and fails, and it is not collected (default on failure), and the system soft-reboots, any new transient unit might conflict as the counter will restart: Failed to start transient service unit: Unit run-u6.service was already loaded or has a fragment file. Get the soft-reboot counter, and if it's greater than zero, append it to the autogenerated unit name to avoid clashes.
* Merge pull request #29721 from poettering/systemd-projectZbigniew Jędrzejewski-Szmek2024-03-261-3/+50
|\ | | | | New capsule@.service feature
| * run: allow connecting to capsule instances with --capsule=/-CLennart Poettering2024-03-141-3/+50
| |
* | tree-wide: Add allow_pidfd argument to bus_append_scope_pidref()Daan De Meyer2024-03-221-10/+5
| |
* | Rename uid0 to run0Zbigniew Jędrzejewski-Szmek2024-03-193-9/+9
|/ | | | | | | | | | | | Naming is always a matter of preference, and the old name would certainly work, but I think the new one has the following advantages: - A verb is better than a noun. - The name more similar to "the competition", i.e. 'sudo', 'pkexec', 'runas', 'doas', which generally include an action verb. - The connection between 'systemd-run' and 'run0' is more obvious. There has been no release yet with the old name, so we can rename without caring for backwards compatibility.
* bus-util: add generic parser for extracting id128 values from bus messagesLennart Poettering2024-03-011-13/+2
|
* run: use sd_event_set_signal_exit() at one more placeLennart Poettering2024-02-261-3/+3
|
* ptyfwd: optionally prefix window title with colored dotLennart Poettering2024-02-231-0/+2
| | | | | | | | | | | | | | in uid0/systemd-run/nspawn we already set a window title with a colorful unicode dot indicating the changed privileges/execution context. This typically gets overriden by the shell inside the environment however. Let's tweak this a bit: when we see the window title OSC ANSI sequence passing through, let's patch in the unicode dot as a prefix to the title. This is super pretty, since it makes sure root sessions via 0ad are really easily recognizable as such, because the window title carries an 🔴 red dot as prefix then.
* signal-util: imply sentinel -1 in sigprocmask_many() + sigset_add_many() ↵Lennart Poettering2024-02-231-1/+1
| | | | args list
* run: set window titleLennart Poettering2024-02-091-1/+31
| | | | | | In interactive terminal mode, let's set a window title that reflects our change of context to the target. Let's prefix it it with red/yellow emoji dot in case we changed privileges.
* pretty-print: split out color tinting into a helper of its ownLennart Poettering2024-01-231-26/+7
|
* run: the --background= switch expects an argumentLennart Poettering2024-01-201-1/+1
| | | | | We got this right when running as "uid0", but wrong when invoked under "systemd-run". Let's fix that.
* run: strjoina is used, not sprintfMike Yuan2024-01-171-3/+3
| | | | Follow-up for 43ead5e3d611e7d3a2e723f5a3cdbf1f8686cea0
* run: don't show IP/IO accounting data if 0Mike Yuan2024-01-121-4/+4
|
* run: show accounting data of same type in the same lineMike Yuan2024-01-121-10/+23
|
* run: use SPECIAL_USER_SLICEAntonio Alvarez Feijoo2024-01-041-1/+2
|
* man: try to improve wording on --slice-inherit docsLennart Poettering2023-12-211-1/+1
|
* run/uid0: tint the terminal background color (and add new --background= switch)Lennart Poettering2023-12-211-1/+57
| | | | | | | | | | | | This adds a new --background= switch that allows specifiying a background color for the terminal while the tool runs. It also teaches the tool when invoked as uid0 to tint the terminal in a reddish hue when operating as root, and in a yellowish hue when operating as any other user. This should highlight nicely when the user is operating with elevated privileges, or changed privileges.
* run: optionally set the "ignore-failure" flag for ExecStart= linesLennart Poettering2023-12-211-2/+11
|
* run: when invoked as "uid0", expose some sudo-like behaviourLennart Poettering2023-12-213-2/+304
| | | | | | | | | This turns "systemd-run" into a multi-call binary. When invoked under the name "uid0", then it behaves a bit more like traditional "sudo". This mostly means defaults appropriuate for that, for example a PAM stack, interactivity and more. Fixes: #29199
* Merge pull request #30537 from poettering/run-arg-service-type-fixYu Watanabe2023-12-201-17/+14
|\ | | | | run: arg_service_type is not supposed to be allocated from heap
| * run: underline section titles in --help as we usually doLennart Poettering2023-12-201-12/+12
| |
| * run: arg_service_type is not supposed to be allocated from heapLennart Poettering2023-12-201-5/+2
| |
* | dbus-wait-for-jobs: change 'quiet' flag to enumMatteo Croce2023-12-191-3/+5
|/ | | | | Change the 'quiet' flag to `bus_wait_for_jobs()` to an enum, so we can select with more granularity the type of information logged.
* run: fix bad escaping and memory ownership confusionZbigniew Jędrzejewski-Szmek2023-12-021-14/+13
| | | | | | | | | | | | | | | arg_description was either set to arg_unit (i.e. a const char*), or to char *description, the result of allocation in run(). But description was decorated with _cleanup_, so it would be freed when going out of the function. Nothing bad would happen, because the program would exit after exiting from run(), but this is just all too messy. Also, strv_join(" ") + shell_escape() is not a good way to escape command lines. In particular, one the join has happened, we cannot distinguish empty arguments, or arguments with whitespace, etc. We have a helper function to do the escaping properly, so let's use that. Fixup for 2c29813da3421b77eca5e5cdc3b9a863cad473b9.
* run: adjust indentationZbigniew Jędrzejewski-Szmek2023-12-021-4/+9
|
* run: escape command for descriptionYu Watanabe2023-11-251-8/+11
| | | | | | | | The command arguments may contain spurious characters, e.g. line-break. When we use command arguments as a description of a unit, we should escape them. Fixes #30187.
* cgroup: add support for memory.swap.peakFlorian Schmaus2023-11-111-0/+6
|
* run: include peak memory in outputFlorian Schmaus2023-11-061-0/+6
| | | | | | Fixes #28542. Signed-off-by: Florian Schmaus <flo@geekplace.eu>
* run: pin the unit we invoke continously while we are runningLennart Poettering2023-10-161-6/+13
| | | | | | We read properties of the unit, hence it shouldn't be GC'ed as long as we run. Hence, let's just set AddRef unconditionally for the units we create.
* run: output invocation ID when starting service and scope unitsLennart Poettering2023-10-161-41/+68
|
* run: support --scope on old service managers that lack native PIDFD supportLennart Poettering2023-10-141-36/+56
| | | | | | Before this we'd fail with a complaint that PIDFDs is not supported by the service manager. Add some compat support by falling back to classic numeric PIDs in that case.
* tree-wide: prefer sending pifds over pids when creating scope unitsLennart Poettering2023-10-051-1/+6
|
* meson: move declarations of busctl, stdio-bridge, and runYu Watanabe2023-08-011-0/+9
|
* run: disable --expand-environment by default for --scopeLuca Boccassi2023-07-201-7/+25
| | | | | | | | | | | | | | | | | | | | | | The intention was to have this option enabled by default everywhere, but unfortunately at least one case was found where it breaks compatibility of a program using systemd-run --scopes and expecting variables not to be expanded: https://sources.debian.org/src/pbuilder/0.231/pbuilder-checkparams/#L400 Example run: systemd-run --quiet --scope --description=pbuilder_build_xfce4-notes-plugin_1.10.0-1.dsc '--slice=system-pbuilder-build-xfce4\x2dnotes\x2dplugin_1.10.0\x2d1-449932.slice' chroot /var/cache/pbuilder/build/449932 dpkg-query -W '--showformat=${Version}' apt Restore backward compatibility and make the option disabled by default when --scope is used, and enabled by default for other types. In case --expand-environment is not specified and a '$' character is detected, print a warning to nudge users toward specifying the parameter as needed. In the future we can then flip the default. Follow-up for 2ed7a221fafb25eea937c4e86fb88ee501dba51e
* env-file: when resolving env vars in command lines, collect list of ↵Lennart Poettering2023-06-271-5/+18
| | | | | | | | | | | unset/invalid ones When resolving environment variables we currently silently resolve unset and invalid environment variables to empty strings. Let's do this slightly less silently: log about unset and invalid env vars, but still resolve them to an empty string. Fixes: #27036
* various: fix error message for bus_wait_for_jobs_new()Zbigniew Jędrzejewski-Szmek2023-05-261-2/+2
| | | | | As pointed out by Mike Yuan in review of grandparent commit, bus_wait_for_jobs_new() can also fail for non-oom reasons.
* run: change sd_bus_call_method to bus_call_method (#27518)Arthur Shau2023-05-041-8/+6
| | | Migrates the sd_bus_call_method code in run.c to use bus-locator.h api
* Merge pull request #27113 from keszybz/variable-expansion-reworkZbigniew Jędrzejewski-Szmek2023-04-241-164/+250
|\ | | | | Rework serialization of command lines in pid1 and make run not expand variables
| * run: expand variables also with --scopeZbigniew Jędrzejewski-Szmek2023-04-241-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes syntax be the same for commands which are started by the manager and those which are spawned directly (when --scope is used). Before: $ systemd-run -q -t echo '$TERM' xterm-256color $ systemd-run -q --scope echo '$TERM' $TERM Now: $ systemd-run -q --scope echo '$TERM' xterm-256color Previous behaviour can be restored via --expand-environment=no: $ systemd-run -q --scope --expand-environment=no echo '$TERM' $TERM Fixes #22948. At some level, this is a compat break. Fortunately --scope is not very widely used, so I think we can get away with this. Having different syntax depending on whether --scope was used or not was bad UX. A NEWS entry will be required.
| * run: add --expand-environment=no to disable server-side envvar expansionZbigniew Jędrzejewski-Szmek2023-04-241-51/+98
| | | | | | | | | | | | | | | | | | | | This uses StartExecEx to get the equivalent of ExecStart=:. StartExecEx was added in b3d593673c5b8b0b7d781fd26ab2062ca6e7dbdb, so this will not work with older systemds. A hint is emitted if we get an error indicating lack of support. PID1 returns SD_BUS_ERROR_PROPERTY_READ_ONLY, but I'm checking for SD_BUS_ERROR_UNKNOWN_PROPERTY too for safety.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 14:15:39 +0100