overlord: save fails with sockets in folder

[mapero]

When making snapshots, the snap will fail when socket files are in the directory:

error: cannot perform the following tasks:
- Save data of snap "rexroth-automationcore" in snapshot set #7 (cannot create archive: tar: 169/.datalayer/backend/2070: socket ignored (and 3 more))
- Save data of snap "rexroth-deviceadmin" in snapshot set #7 (cannot create archive: tar: x1/auth-service/token-validation.sock: socket ignored (and 2 more))

This PR will ignore such warnings and will not fail the tar run:

From https://www.gnu.org/software/tar/manual/html_section/tar_27.html

file-ignored
`%s: Unknown file type; file ignored'
`%s: socket ignored'
`%s: door ignored'

Fixes: https://bugs.launchpad.net/bugs/1915781

[stolowski]

I think this looks sensible, thanks for investigating this!

The --exclude* mechanism of tar (that you mentioned in the bug report) is pattern-based, so would only help if we extended snapshots functionality with user-defined exclusion list but I'm not sure users should be bothered with this.

[bboozzoo]

I wonder if we should silently ignore the files instead of logging which were ignored.

Also, from my silly attempts with sockets in a directory, tar the same command line (but without no-file-ignored), does not exit with non-0. Then I proceeded to create sockets and fifos in $SNAP_DATA and $SNAP_COMMON of hello-world, and snap save worked. I think there may have been more errors logged by tar, but they were not included in the error output of the task.

[mapero]

You are right, the sockets ignored was hiding the actual cause of the error

tar: ./171/.datalayer/frontend/2069: socket ignored
tar: ./171/.datalayer/backend/2070: socket ignored
tar: ./171/package-run/rexroth-automationcore/package-www-fileserver.sock: socket ignored
tar: ./171: file changed as we read it
1

We found the cause on our side for this. But it would be helpful to have the "real" error cause in the log of the snap change.

[mapero]

I think this looks sensible, thanks for investigating this!

The --exclude* mechanism of tar (that you mentioned in the bug report) is pattern-based, so would only help if we extended snapshots functionality with user-defined exclusion list but I'm not sure users should be bothered with this.

For me it would be more the developer that should define what should be excluded during snapshot. If you have sensible data in your snap they maybe should not be part of a snapshot (since you can export them now).
Currently all snap specific folders are part of the snapshot, there is no way where you can store data that should be ignored during snapshot.

[stolowski]

Removing my review per @bboozzoo finding (thank you!).

[bboozzoo]

Closing this for now. Looks like the root cause of the problem was caused by $SNAP_DATA directory getting modified while tar was processing it.

[bboozzoo]

@mapero please take a look at #9953