skip hidden directories in load task, and return soon if path not exist
in atomicDelete
carry of #3233Closes#3233
Signed-off-by: Ace-Tang <aceapril@126.com>
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
make ctr shim command easy to use for user, shim socket is generated
through sha256, and it can not get directly, change socket flag to id
command, generated socket in code.
It also avoid fail to connect shim v2, since shim v2 have multiple
containers, `ctr shim --socket state` should specify container id, or
get error `rpc error: code = NotFound desc = container not created: not
found`
Signed-off-by: Ace-Tang <aceapril@126.com>
Currently when we restart containerd it will load all tasks with shim
logs whether the `shim_debug` is set or not.
Signed-off-by: Li Yuxuan <liyuxuan04@baidu.com>
Pervent travis from timing out because no output was printed;
No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit improves ARM platform matching in two instances:
* Some old kernels reported the CPU architecture of arm64 cpus as
Aarch64 [1].
* In cases where the user is running with armv8 cpu and kernel but amrhf
user land (so armhf containerd), a possibility given the compatibility
of armv8 with armv7.
[1] https://elixir.bootlin.com/linux/v3.14.29/source/arch/arm64/kernel/setup.c#L420
Signed-off-by: Jaime Caamaño Ruiz <jcaamano@suse.com>
Open shim v2 log with the flag `O_RDWR` will cause the `Read()` block
forever even if the pipe has been closed on the shim side. Then the
`io.Copy()` would never return and lead to a fd leak.
Fix typo when closing shim v1 log which causes the `stdouLog` leak.
Update `numPipes` function in test case to get the opened FIFO
correctly.
Signed-off-by: Li Yuxuan <liyuxuan04@baidu.com>
For block device like devicemapper, umount before committing
active snapshot can sync data onto disk. Otherewise:
1. deactivating a block device in use will fail or IO error
when forced;
2. new snapshot on it will not catch the data not laid on disk yet.
Signed-off-by: Eric Ren <renzhen.rz@alibaba-linux.com>
1. reason to deactivate committed snapshot
The thin device will not be used for IO after committed,
and further thin snapshotting is OK using an inactive thin
device as origin. The benefits to deactivate are:
- device is not unneccesary visible avoiding any unexpected IO;
- save useless kernel data structs for maintaining active dm.
Quote from kernel doc (Documentation/device-mapper/provisioning.txt):
"
ii) Using an internal snapshot.
Once created, the user doesn't have to worry about any connection
between the origin and the snapshot. Indeed the snapshot is no
different from any other thinly-provisioned device and can be
snapshotted itself via the same method. It's perfectly legal to
have only one of them active, and there's no ordering requirement on
activating or removing them both. (This differs from conventional
device-mapper snapshots.)
"
2. an thinpool metadata bug is naturally removed
An problem happens when failed to suspend/resume origin thin device
when creating snapshot:
"failed to create snapshot device from parent vg0-mythinpool-snap-3"
error="failed to save initial metadata for snapshot "vg0-mythinpool-snap-19":
object already exists"
This issue occurs because when failed to create snapshot, the
snapshotter.store can be rollbacked, but the thin pool metadata
boltdb failed to rollback in PoolDevice.CreateSnapshotDevice(),
therefore metadata becomes inconsistent: the snapshotID is not
taken in snapshotter.store, but saved in pool metadata boltdb.
The cause is, in PoolDevice.CreateSnapshotDevice(), the defer calls
are invoked on "first-in-last-out" order. When the error happens
on the "resume device" defer call, the metadata is saved and
snapshot is created, which has no chance to be rollbacked.
Signed-off-by: Eric Ren <renzhen@linux.alibaba.com>
This patch adds the OpenLab CI configuration to enable
the support for arm build in OpenLab.
After this, each pull request in containerd will trigger the
containerd-arm64-build job which verified the arm build
on OpenLab ARM cluster.
Related: https://github.com/containerd/containerd/issues/2901
Signed-off-by: Yikun Jiang <yikunkero@gmail.com>
