summaryrefslogtreecommitdiff
path: root/library/std/src/sys/unix/process/process_unix.rs
Commit message (Collapse)AuthorAgeFilesLines
* Spelling library/Josh Soref2023-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * advance * aligned * borrowed * calculate * debugable * debuggable * declarations * desugaring * documentation * enclave * ignorable * initialized * iterator * kaboom * monomorphization * nonexistent * optimizer * panicking * process * reentrant * rustonomicon * the * uninitialized Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
* Retry to spawn/fork up to 3 times when it failed because of an interruptionFlorian Bartels2023-02-281-2/+64
|
* Add QNX Neutrino support to libstdFlorian Bartels2023-02-281-3/+7
| | | | Co-authored-by: gh-tr <troach@qnx.com>
* signal update string representation for haiku.David Carlier2023-01-181-0/+2
|
* Remove various double spaces in source comments.André Vennberg2023-01-141-3/+3
|
* Rollup merge of #105458 - Ayush1325:blocking_spawn, r=Mark-SimulacrumMatthias Krüger2022-12-171-0/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow blocking `Command::output` ### Problem Currently, `Command::output` is internally implemented using `Command::spawn`. This is problematic because some targets (like UEFI) do not actually support multitasking and thus block while the program is executing. This coupling does not make much sense as `Command::output` is supposed to block until the execution is complete anyway and thus does not need to rely on a non-blocking `Child` or any other intermediate. ### Solution This PR moves the implementation of `Command::output` to `std::sys`. This means targets can choose to implement only `Command::output` without having to implement `Command::spawn`. ### Additional Information This was originally conceived when working on https://github.com/rust-lang/rust/pull/100316. Currently, the only target I know about that will benefit from this change is UEFI. This PR can also be used to implement more efficient `Command::output` since the intermediate `Process` is not actually needed anymore, but that is outside the scope of this PR. Since this is not a public API change, I'm not sure if an RFC is needed or not.
| * Implement blocking outputAyush Singh2022-12-111-0/+5
| | | | | | | | | | | | | | | | | | | | This allows decoupling `Command::spawn` and `Command::output`. This is useful for targets which do support launching programs in blocking mode but do not support multitasking (Eg: UEFI). This was originally conceived when working on https://github.com/rust-lang/rust/pull/100316 Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
* | explain mem::forget(env_lock) in fork/execRalf Jung2022-12-121-3/+4
|/
* Change process spawning to inherit the parent's signal mask by defaultRain2022-10-201-33/+39
| | | | | | | | | | | Previously, the signal mask is always reset when a child process is started. This breaks tools like `nohup` which expect `SIGHUP` to be blocked. With this change, the default behavior changes to inherit the signal mask. This also changes the signal disposition for `SIGPIPE` to only be changed if the `#[unix_sigpipe]` attribute isn't set.
* Remove use of `io::ErrorKind::Other` in stdPatiga2022-09-201-2/+2
| | | | | | The documentation states that this `ErrorKind` is not used by the standard library. Instead, `io::ErrorKind::Uncategorized` should be used.
* Use posix_spawn for absolute paths on macOSRain2022-08-281-1/+3
| | | | | | | | | | | | | | Currently, on macOS, Rust never uses the fast posix_spawn path if a directory change is requested due to a bug in Apple's libc. However, the bug is only triggered if the program is a relative path. This PR makes it so that the fast path continues to work if the program is an absolute path or a lone filename. This was an alternative proposed in https://github.com/rust-lang/rust/pull/80537#issue-776674009, and it makes a measurable performance difference in some of my code that spawns thousands of processes.
* Remove SIGIO reference on HaikuRyan Zoeller2022-06-051-0/+1
| | | | | Haiku doesn't define SIGIO. The nix crate already employs this workaround: https://github.com/nix-rust/nix/blob/5dedbc7850448ae3922ab0a833f3eb971bf7e25f/src/sys/signal.rs#L92-L94
* Auto merge of #95833 - notriddle:notriddle/human-readable-signals, r=yaahcbors2022-06-031-3/+79
|\ | | | | | | | | | | std: `<ExitStatus as Display>::fmt` name the signal it died from Related to #95601
| * Fix MIPS-specific signal bugMichael Howell2022-06-021-1/+10
| |
| * std: show signal number along with nameMichael Howell2022-06-011-43/+47
| |
| * std: `<ExitStatus as Display>::fmt` name the signal it died fromMichael Howell2022-04-231-0/+63
| |
* | Use Rust 2021 prelude in std itself.Mara Bos2022-05-091-1/+0
| |
* | Auto merge of #93530 - anonion0:pthread_sigmask_fix, r=JohnTitorbors2022-04-171-1/+2
|\ \ | |/ |/| | | | | | | | | | | | | fix error handling for pthread_sigmask(3) Errors from `pthread_sigmask(3)` were handled using `cvt()`, which expects a return value of `-1` on error and uses `errno`. However, `pthread_sigmask(3)` returns `0` on success and an error number otherwise. Fix it by replacing `cvt()` with `cvt_nz()`.
| * move import to fix warning with emscripten targetRalf Sager2022-04-171-1/+2
| |
| * fix error handling for pthread_sigmask(3)Ralf Sager2022-01-311-2/+2
| | | | | | | | | | | | | | | | Errors from pthread_sigmask(3) were handled using cvt(), which expects a return value of -1 on error and uses errno. However, pthread_sigmask(3) returns 0 on success and an error number otherwise. Fix it by replacing cvt() with cvt_nz().
* | Rollup merge of #93858 - krallin:process-process_group, r=dtolnayDylan DPC2022-03-191-1/+14
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a `process_group` method to UNIX `CommandExt` - Tracking issue: #93857 - RFC: https://github.com/rust-lang/rfcs/pull/3228 Add a `process_group` method to `std::os::unix::process::CommandExt` that allows setting the process group id (i.e. calling `setpgid`) in the child, thus enabling users to set process groups while leveraging the `posix_spawn` fast path.
| * | Add a `process_group` method to UNIX `CommandExt`Thomas Orozco2022-03-141-1/+14
| | |
* | | Rollup merge of #92612 - atopia:update-lib-l4re, r=dtolnayDylan DPC2022-03-191-1/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | Update stdlib for the l4re target This PR contains the work by ``@humenda`` and myself to update standard library support for the x86_64-unknown-l4re-uclibc tier 3 target, split out from humenda/rust as requested in #85967. The changes have been rebased on current master and updated in follow up commits by myself. The publishing of the changes is authorized and preferred by the original author. To preserve attribution, when standard library changes were introduced as part of other changes to the compiler, I have kept the changes concerning the standard library and altered the commit messages as indicated. Any incompatibilities have been remedied in follow up commits, so that the PR as a whole should result in a clean update of the target.
| * | | drop unused libc imports on L4ReBenjamin Lamowski2022-03-091-1/+4
| | | | | | | | | | | | | | | | | | | | As a capability-based microkernel OS, L4Re only has incomplete support for POSIX APIs, in particular it does not implement UIDs and GIDs.
* | | | feat: Add use of bool::then in sys/unix/processwcampbell2022-03-171-3/+3
| | | | | | | | | | | | | | | | Remove else { None } in favor of using bool::then()
* | | | Use implicit capture syntax in format_argsT-O-R-U-S2022-03-101-5/+5
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).
* | | Provide C FFI types via core::ffi, not just in stdJosh Triplett2022-03-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ability to interoperate with C code via FFI is not limited to crates using std; this allows using these types without std. The existing types in `std::os::raw` become type aliases for the ones in `core::ffi`. This uses type aliases rather than re-exports, to allow the std types to remain stable while the core types are unstable. This also moves the currently unstable `NonZero_` variants and `c_size_t`/`c_ssize_t`/`c_ptrdiff_t` types to `core::ffi`, while leaving them unstable.
* | | Hide Repr details from io::Error, and rework `io::Error::new_const`.Thom Chiovoloni2022-02-041-8/+5
|/ /
* | Refactor weak symbols in std::sys::unixJosh Stone2021-11-121-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes a few changes to the weak symbol macros in `sys::unix`: - `dlsym!` is added to keep the functionality for runtime `dlsym` lookups, like for `__pthread_get_minstack@GLIBC_PRIVATE` that we don't want to show up in ELF symbol tables. - `weak!` now uses `#[linkage = "extern_weak"]` symbols, so its runtime behavior is just a simple null check. This is also used by `syscall!`. - On non-ELF targets (macos/ios) where that linkage is not known to behave, `weak!` is just an alias to `dlsym!` for the old behavior. - `raw_syscall!` is added to always call `libc::syscall` on linux and android, for cases like `clone3` that have no known libc wrapper. The new `weak!` linkage does mean that you'll get versioned symbols if you build with a newer glibc, like `WEAK DEFAULT UND statx@GLIBC_2.28`. This might seem problematic, but old non-weak symbols can tie the build to new versions too, like `dlsym@GLIBC_2.34` from their recent library unification. If you build with an old glibc like `dist-x86_64-linux` does, you'll still get unversioned `WEAK DEFAULT UND statx`, which may be resolved based on the runtime glibc. I also found a few functions that don't need to be weak anymore: - Android can directly use `ftruncate64`, `pread64`, and `pwrite64`, as these were added in API 12, and our baseline is API 14. - Linux can directly use `splice`, added way back in glibc 2.5 and similarly old musl. Android only added it in API 21 though.
* Rollup merge of #90704 - ijackson:exitstatus-comments, r=joshtriplettMatthias Krüger2021-11-121-0/+3
|\ | | | | | | | | | | Unix ExitStatus comments and a tiny docs fix Some nits left over from #88300
| * unix::ExitStatus: Add comment saying that it's a wait statusIan Jackson2021-11-111-0/+3
| | | | | | | | | | | | With cross-reference. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
* | Also note tool expectations of fork vs clone3Josh Stone2021-11-051-0/+2
| | | | | | | | Co-authored-by: Josh Triplett <josh@joshtriplett.org>
* | Update another comment on fork vs. clone3Josh Stone2021-11-051-2/+2
| |
* | Only use `clone3` when needed for pidfdJosh Stone2021-11-051-7/+6
|/ | | | | | In #89522 we learned that `clone3` is interacting poorly with Gentoo's `sandbox` tool. We only need that for the unstable pidfd extensions, so otherwise avoid that and use a normal `fork`.
* Rollup merge of #88828 - FabianWolff:issue-88585, r=dtolnayManish Goregaokar2021-10-051-3/+13
|\ | | | | | | | | | | | | | | | | | | | | Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlock Fixes #88585. POSIX [specifies](https://man7.org/linux/man-pages/man3/fork.3p.html) that after forking, > to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Rust's standard library does not currently adhere to this, as evidenced by #88585. The child process calls [`sys::signal()`](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/android.rs#L76), which on Android calls [`libc::dlsym()`](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/weak.rs#L101), which is [**not**](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, and in fact causes a deadlock in the example in #88585. I think the easiest solution here would be to just call `libc::sigaction()` instead, which [is](https://man7.org/linux/man-pages/man7/signal-safety.7.html) async-signal-safe, provides the functionality we need, and is apparently available on all Android versions because it is also used e.g. [here](https://github.com/rust-lang/rust/blob/7bf0736e130e2203c58654f7353dbf9575e49d5c/library/std/src/sys/unix/stack_overflow.rs#L112-L114).
| * Call `libc::sigaction()` only on AndroidFabian Wolff2021-10-011-3/+14
| |
| * Clean up unneeded explicit pointer castDavid Tolnay2021-09-281-1/+1
| | | | | | | | | | | | | | The reference automatically coerces to a pointer. Writing an explicit cast here is slightly misleading because that's most commonly used when a pointer needs to be converted from one pointer type to another, e.g. `*const c_void` to `*const sigaction` or vice versa.
| * Use `libc::sigaction()` instead of `sys::signal()` to prevent a deadlockFabian Wolff2021-09-101-4/+3
| |
* | Rollup merge of #88305 - ijackson:exitstatus-debug, r=dtolnayManish Goregaokar2021-10-031-2/+14
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Manual Debug for Unix ExitCode ExitStatus ExitStatusError These structs have misleading names. An ExitStatus[Error] is actually a Unix wait status; an ExitCode is actually an exit status. These misleading names appear in the `Debug` output. The `Display` impls on Unix have been improved, but the `Debug` impls are still misleading, as reported in #74832. Fix this by pretending that these internal structs are called `unix_exit_status` and `unix_wait_status` as applicable. (We can't actually rename the structs because of the way that the cross-platform machinery works: the names are cross-platform.) After this change, this program ``` #![feature(exit_status_error)] fn main(){ let x = std::process::Command::new("false").status().unwrap(); dbg!(x.exit_ok()); eprintln!("x={:?}",x); } ``` produces this output ``` [src/main.rs:4] x.exit_ok() = Err( ExitStatusError( unix_wait_status( 256, ), ), ) x=ExitStatus(unix_wait_status(256)) ``` Closes #74832
| * | Manual Debug for Unix ExitCode ExitStatus ExitStatusErrorIan Jackson2021-08-241-2/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | These structs have misleading names. An ExitStatus[Error] is actually a Unix wait status; an ExitCode is actually an exit status. The Display impls are fixed, but the Debug impls are still misleading, as reported in #74832. Fix this by pretending that these internal structs are called `unix_exit_status` and `unix_wait_status` as applicable. (We can't actually rename the structs because of the way that the cross-platform machinery works: the names are cross-platform.) Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
* | Remove unnecessary unsafe block in `process_unix`Léo Lanteri Thauvin2021-08-241-2/+1
|/
* Fix an unused import warning.Dan Gohman2021-08-191-1/+1
|
* Update PidFd for the new I/O safety APIs.Dan Gohman2021-08-191-5/+11
|
* Add tracking issue and link to man-pageDominik Stolz2021-07-211-1/+1
|
* Add PidFd type and seal traitsDominik Stolz2021-07-211-84/+116
| | | | | | | | | | | | Improve docs Split do_fork into two Make do_fork unsafe Add target attribute to create_pidfd field in Command Add method to get create_pidfd value
* Typo fixJosh Triplett2021-07-211-1/+1
| | | Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
* Add Linux-specific pidfd process extensionsAaron Hill2021-07-211-6/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Background: Over the last year, pidfd support was added to the Linux kernel. This allows interacting with other processes. In particular, this allows waiting on a child process with a timeout in a race-free way, bypassing all of the awful signal-handler tricks that are usually required. Pidfds can be obtained for a child process (as well as any other process) via the `pidfd_open` syscall. Unfortunately, this requires several conditions to hold in order to be race-free (i.e. the pid is not reused). Per `man pidfd_open`: ``` · the disposition of SIGCHLD has not been explicitly set to SIG_IGN (see sigaction(2)); · the SA_NOCLDWAIT flag was not specified while establishing a han‐ dler for SIGCHLD or while setting the disposition of that signal to SIG_DFL (see sigaction(2)); and · the zombie process was not reaped elsewhere in the program (e.g., either by an asynchronously executed signal handler or by wait(2) or similar in another thread). If any of these conditions does not hold, then the child process (along with a PID file descriptor that refers to it) should instead be created using clone(2) with the CLONE_PIDFD flag. ``` Sadly, these conditions are impossible to guarantee once any libraries are used. For example, C code runnng in a different thread could call `wait()`, which is impossible to detect from Rust code trying to open a pidfd. While pid reuse issues should (hopefully) be rare in practice, we can do better. By passing the `CLONE_PIDFD` flag to `clone()` or `clone3()`, we can obtain a pidfd for the child process in a guaranteed race-free manner. This PR: This PR adds Linux-specific process extension methods to allow obtaining pidfds for processes spawned via the standard `Command` API. Other than being made available to user code, the standard library does not make use of these pidfds in any way. In particular, the implementation of `Child::wait` is completely unchanged. Two Linux-specific helper methods are added: `CommandExt::create_pidfd` and `ChildExt::pidfd`. These methods are intended to serve as a building block for libraries to build higher-level abstractions - in particular, waiting on a process with a timeout. I've included a basic test, which verifies that pidfds are created iff the `create_pidfd` method is used. This test is somewhat special - it should always succeed on systems with the `clone3` system call available, and always fail on systems without `clone3` available. I'm not sure how to best ensure this programatically. This PR relies on the newer `clone3` system call to pass the `CLONE_FD`, rather than the older `clone` system call. `clone3` was added to Linux in the same release as pidfds, so this shouldn't unnecessarily limit the kernel versions that this code supports. Unresolved questions: * What should the name of the feature gate be for these newly added methods? * Should the `pidfd` method distinguish between an error occurring and `create_pidfd` not being called?
* Change `weak!` and `linkat!` to macros 2.0Aris Merchant2021-07-101-0/+8
| | | | | | | `weak!` is needed in a test in another module. With macros 1.0, importing `weak!` would require reordering module declarations in `std/src/lib.rs`, which is a bit too evil.
* Add `ExitStatusError` for `vxworks`Christiaan Dirkx2021-05-201-1/+1
|
* Auto merge of #82973 - ijackson:exitstatuserror, r=yaahcbors2021-05-181-3/+28
|\ | | | | | | | | | | | | | | | | | | Provide ExitStatusError Closes #73125 In MR #81452 "Add #[must_use] to [...] process::ExitStatus" we concluded that the existing arrangements in are too awkward so adding that `#[must_use]` is blocked on improving the ergonomics. I wrote a mini-RFC-style discusion of the approach in https://github.com/rust-lang/rust/issues/73125#issuecomment-771092741
View Lorry Controller Status