attic does not backup UNIX domain sockets

[ThomasWaldmann]

On the mailing list, Dan Williams (2015-04-01) reported an issue with attic master branch code:

"""
There was one problem restoring, however: Attic failed to restore a socket
file. Ouch! The other two [obnam and bup] restored the file just fine.
"""

Can somebody else reproduce this?

[ThomasWaldmann]

I could reproduce it. Easy way to create a socket: ncat -l -U /tmp/mysock

It won't be in a attic 0.14 backup, see below.

[ThomasWaldmann]

from attic/archiver.py:157:

        # Ignore unix sockets
        if stat.S_ISSOCK(st.st_mode):
            return

So, it is expected with current code that you won't have UNIX Domain Sockets in your backup.

So the remaining questions are "why not" and "why would one want them"?

I admit I have not much clue about UDS, so if someone can help with reasoning here, that would be welcome.

[ThomasWaldmann]

Just tried the good ol' tar:

tar: /tmp/mysock: socket ignored

So, tar doesn't backup UDS either. Just saying, the reasoning why or why not is still todo.

[Ernest0x]

Backup / archiving tools that ignore sockets "know" that software will create or recreate a socket if it needs to and will bind or rebind it to a path name. So, backing up sockets makes no sense.

[danwilliams]

That's curious; I must admit I did not realise that tar skips sockets. A quick Google suggest that it's not even optional; it just skips them.

However, a better question from my point of view is, "should a backup program backup sockets?", rather than looking purely at tar. On this point, both Bup and Obnam backup, and restore, sockets. Equally, rsync will copy sockets, so I assume (I have not tested this theory) that rsync-based tools do too. Because of this, I was expecting Attic to do so.

Again, a quick Google suggests that there may be no purpose in backing up and/or restoring sockets. This is the conclusion of this thread on superuser. However, I am not sure that is the end of the question; I have two observations:

1. What if the program that usually uses the socket, and owned the socket, had permissions to use that socket but with it gone cannot recreate it, because it does not have permission on the containing folder? E.g. if the folder is owned by root. This would recreate user intervention to recreate the socket or change permissions. I am not sure if this is realistic, though, seeing as users generally don't have to create sockets!
2. To anyone running a backup and restore, and comparing the result, if the restored filesystem is missing sockets then they will get a different number of files. This is what I encountered, and it was unexpected. The user would have to verify that all the missing files were sockets, or do their comparison explicitly excluding sockets. I'm not sure this is obvious or intuitive.

Does it do any harm to backup and restore the sockets? In balance, it seems better, from a user's point of view? And the program using it will just recreate it either way. Perhaps this is why other tools do it?

[ThomasWaldmann]

After first implementing "socket backup/restore support", I read that superuser discussion and esp. this:

Q: How to backup/restore unix domain sockets?

A: You don't.

Unix local sockets are created as soon as a program attempts to listen on the
given path for connections, and despite being a type of file they only act as pointers
to in-memory structures; so they are useful only as long as the program is still
running (and only within the same machine; no NFS or anything such).

After the program exits, the socket file is no longer useful (and is normally deleted
by the program itself); in fact, if the program gets restarted, it has to delete the old
socket before listening on the same path – otherwise it would receive an
"Address already in use" (the same as if two programs were trying to take the
same TCP port).

This is somewhat different from named pipes (aka fifos), which work in a much
simpler way (one process writes, one process reads) and therefore are reusable;
a named pipe can be created using the mkfifo or mknod p … commands.

I also tried that myself and can confirm it: there is no point in re-using a restored UDS. The program that tries to listen on it will just fail. The program must be able to delete a existing UDS first to be able to listen on (and create) a fresh one. If it can't delete or create due to missing permissions, it can not work.

So, argument 1 is invalid.

About argument 2: we could backup and restore UDS on a "it was there when we backed up, it will be there after restore (even if not really connected and pretty useless)" basis. An advantage of this would be that we do not have to tell "ignored socket" like tar does (and confuse everybody who does not know details about how UDS work).

Opinions?

[ThomasWaldmann]

If someone wants to give it another test:

https://github.com/ThomasWaldmann/attic/commits/uds

[danwilliams]

Cool, I can't remember ever having created or used a socket file myself for anything I've worked on, so I was unsure as to some of the finer points. The superuser discussion was quite informative and convincing, and if you have tested the conditions I speculated on in my first point, I am quite happy with your conclusion. (And it sounds logical, because to delete the socket, write permissions are required on the containing folder, etc.)

So I think we are all in agreement that there is no technical need to backup sockets.

I have thought quite a bit about point 2. I ultimately think that sockets should be backed up. My thinking goes like this:

• If a file exists (of whatever nature) and is not restored, this can be unsettling for users checking integrity. Users should not have to learn about sockets or perform extra steps in data comparison to exclude them (this is essentially my point 2).
• It should not be the responsibility of the backup software to decide what is "useless". This is something I thought about for a long time! There may well be other files or filesystem entities present which, upon restoration, could be useless. Where do we draw the line? E.g. a broken symlink, a special device for something inaccessible (say a floppy drive). So there are quite a few circumstances that I could think of under which "useless" or invalid data could be restored - and I do not think that is a problem. The key point to me is that the backup software should faithfully duplicate exactly what it finds, regardless.
• The end state, having restored a socket, is - from what I can tell - no different to the state encountered if the program owning the socket had quit (assuming it left the socket behind). So this is not a bad thing. Although, it does ask the question about what would/should happen if restoring to a place where there are existing files and an existing socket. But that's probably off-topic here.

Of course, all this is just my personal opinion - I'm not even contributing to the codebase! So I can hardly complain if you disagree :o)

However:

• If sockets are not to be supported, there should be some mention of this in the documentation, loud and clear so people will know what to expect.
• If sockets are to be supported, it may also be worth considering implementing an option to exclude them from either the backup, or the restore, or both. This could also apply to other special files, perhaps - but may be unnecessary on the restore side because I guess someone could run find -xdev and pipe to Attic over stdin. Either way, I'd definitely prefer the default to be "on" and the option to turn them "off", rather than the other way around.

Regarding your patch: I will test this in the next couple of days; once I have finished my current tests with official Attic my plan is to rebuild my Debian packages based on the merge-all branch and give that a spin, at which point I will also include your UDS commit.

[Ernest0x]

Restoring a socket file is not only useless, but will possibly also overwrite an already bound socket. This is bad because applications will not be able to connect to the service that binds the socket until that service recreates it. Many applications are not coded to be able to recover from this and will need to be restarted. So, please, do not break this.

[danwilliams]

If restoring into a location that already has content, you could say the same about other files - for instance, any PID files or files in use by flock. Restoring these files could therefore also cause problems. What would you have Attic (or any backup tool) do in this situation?

I would be happy if the default behaviour were to skip restoring sockets if they already exist. This seems sensible enough and would not cause any problems. Arguably the user could/should be informed about this. I do however see no purpose in adding an option to force-overwrite sockets, as this would be pointless due to their nature. But an option to filter them out when restoring could perhaps be useful to some people.

[Ernest0x]

If restoring into a location that already has content, you could say the same about other files - for instance, any PID files or files in use by flock. Restoring these files could therefore also cause problems. What would you have Attic (or any backup tool) do in this situation?

You will normally exclude PID files as well as any other type of files that you do not need to backup, as you do not need to restore them. The good thing with socket files is that they are special, so we can hardcode their exclusion in the backup tools.

I would be happy if the default behaviour were to skip restoring sockets if they already exist. This seems sensible enough and would not cause any problems.

Don't be so sure. It could happen that the service creates the socket right after the restoration tool checked for the existence of the path, but before the restoration takes place.

Arguably the user could/should be informed about this. I do however see no purpose in adding an option to force-overwrite sockets, as this would be pointless due to their nature. But an option to filter them out when restoring could perhaps be useful to some people.

I would say the oposite. By default, do not backup socket files, but have an option if someone (like you) insists in taking backups of these.

[danwilliams]

You will normally exclude PID files as well as any other type of files that you do not need to backup, as you do not need to restore them.

That's a rather sweeping statement - do you really mean that for every backup you do, you carefully check where all the PID files are and write exclusion lists for them? And that you know this list is complete, and that you keep it up-to-date? If so, that is remarkable - and I suspect not many other people would do this. I have never bothered, as I can't see the point. I would rather have a backup that gathers up everything possible.

Regarding the sockets specifically, of the tools I tested, Attic was the only one that did not backup and restore sockets. My sample pool is rather small and I should probably investigate other tools, but the writer of Obnam in particular strikes me as rather pedantic about data integrity (which is a good thing) and so must have thought through this very problem.

It could happen that the service creates the socket right after the restoration tool checked for the existence of the path, but before the restoration takes place.

This seems like an extremely unlikely event.

I would say the oposite. By default, do not backup socket files, but have an option if someone (like you) insists in taking backups of these.

What is more intuitive for the general user - to do everything, or to miss bits out?

This is certainly an interesting debate - I had no idea people were so passionate about sockets! (Myself included!) ;o)