This avoids dereferencing c.config.Spec.Linux if it is nil, which is the
case on FreeBSD.
[NO NEW TESTS NEEDED]
Signed-off-by: Doug Rabson <dfr@rabson.org>
This fixes a regression added in commit 4fd84190b8, because the name was
overwritten by the createTimer() timer call the removeTransientFiles()
call removed the new timer and not the startup healthcheck. And then
when the container was stopped we leaked it as the wrong unit name was
in the state.
A new test has been added to ensure the logic works and we never leak
the system timers.
Fixes#22884
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is a bit weird and I admit I don't understand exactly how the init
value is used but this seems wrong. When podman reexec itself it then
gets the wrong init value and because rootless_uid() will be 0 the
init() function in rootless_linux.go will not set it either because of
that. Thus the first reexec has the wrong env.
Now that I make use of it in c/common[1] this turns out top be a real
issue and is failing all first podman commands. To reproduce make sure
to kill the pause process then just run any podman command with the new
c/common vendor and without this patch.
[1] https://github.com/containers/common/pull/2020
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
debian's man (5) hostname page states "The file should contain a single newline-terminated hostname
string."
[NO NEW TESTS NEEDED]
fix#22729
Signed-off-by: Bo Wang <wangbob@uniontech.com>
runlabel` should be `podman container runlabel`. Note: I am not fixing
past references before this on purpose.
Fixes#22871
Signed-off-by: Brent Baude <bbaude@redhat.com>
The e2e tests already depend on skopeo anyway and pulling a over 300
MB image is not helpful for flakes but most importantly we see ENOSPC
flakes. I see them around the skopeo test so I assume the big image is
pushing the tmpfs limits so other tests running in parallel can start
failing because of it.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The path mentioned above is linked in the sysadmin
article on running podman inside containers. The content
has since been moved and users are getting a 404 there now.
Add the path back with a readme pointing to the new location
of the content.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
The expectation with --cgroups=disabled is that the current cgroup is
used by the container.
Currently the --cgroups=disabled is passed directly to the OCI
runtime, but it doesn't stop Podman from creating a new cgroup when it
doesn't own the current one.
Closes: https://github.com/containers/podman/issues/20910
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
the condition doesn't work when the runtime to use is specified
through its absolute path as the error message contains that.
Simplify the check and just look for "read from the init process".
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Another new-VM import from
https://github.com/containers/automation_images/pull/338
...because the usual conflict dealio in that repo. This
should mostly be a NOP. All the major work was done in #22706.
Signed-off-by: Ed Santiago <santiago@redhat.com>
podman.msi GUI has a radio-button to select WSL or Hyper-V
The checkbox in podman.msi GUI allow the user to specify if
the machine provider installation (WSL or Hyper-V) should
be part of podman installation or not.
podman-setup.exe supports 2 new variables: MachineProvider
(valid values are `wsl` and `hyperv`) and HyperVCheckbox
(valid values are `0` and `1`)
Installation creates the configuration file
`99-podman-machine-provider.conf` under folder
`%APPDATA\containers\containers.conf.d` with the selected
machine provider
Cirrus CI `win_installer_task` tests the installation with
both `hyperv` and `wsl` and verifies the configuration.
Uninstallation is tested too.
Note that podman-setup.exe GUI doesn't allow to choose the
provider yet. See https://github.com/containers/podman/issues/22492
Signed-off-by: Mario Loriedo <mario.loriedo@gmail.com>
