Line 11: |
Line 11: |
| == Using the option == | | == Using the option == |
| | | |
− | However, sometimes it is possible to dump and successfully restore only one end of a unix socket pair. One particular example is the <code>logd</code>, a daemon which opens a datagram unix socket and waits on it for messages to be written into a log file. Processes using logd also create datagram unix sockets and connect those to the logd socket. These connections are thus uni-directional, meaning that the logd's socket remains unconnected. In this case it is possible to dump a program using logd as a client. For it to work after restore its socket needs to be reconnected back to logd using the logd's socket name. | + | However, sometimes it is possible to dump and successfully restore only one end of a unix socket pair. One particular example is the datagram sockets with on-way connection (client to server) used e.g. by <code>logd</code>. Server opens a datagram socket and waits on it for messages to be written into a log file. Processes using logd also create datagram sockets and connect those to the server. These connections are thus uni-directional. In this case it is possible to dump a program with the client-side socket and on restore the socket needs to be reconnected back to the original server. |
| | | |
− | This is when <code>--ext-unix-sk</code> option should be used. By providing this option (for both dump and restore commands), user states "I know there may be uni-directional unix connections, and I will make sure the server end will exist on restore". | + | This is when <code>--ext-unix-sk</code> option should be used. By providing this option (for both dump and restore commands), user states "I know there may be uni-directional dgram unix connections, and I will make sure the server end will exist on restore". |
| | | |
| For '''criu dump''', this option enables dumping ''datagram'' unix sockets with additional information about that other ("external") socket it is connected to. | | For '''criu dump''', this option enables dumping ''datagram'' unix sockets with additional information about that other ("external") socket it is connected to. |
| | | |
| For '''criu restore''', this option asks criu to re-connect such sockets back. | | For '''criu restore''', this option asks criu to re-connect such sockets back. |
| + | |
| + | == Limitations == |
| + | |
| + | Socket screated with socketpair() systemcall are not one-way connected and do not work with --ext-unix-sk |
| + | |
| + | == What to do with stream/seqpacket? == |
| + | |
| + | Such sockets cannot be just dumped and restored as once we dump one end, the other one seen EOF on socket and may close one. The plan for this is to extend the --ext-unix-sk semantics to work like this |
| + | |
| + | * On dump the <code>--ext-unix-sk $id</code> says that socket with $id is OK to be disconnected |
| + | * On restore the <code>--ext-unix-sk$id[=$path]</code> says that the socket $id should be reconnected back to the path it say on dump (or to the $path). |
| + | |
| + | This won't work for socketpair()-s also. |
| + | |
| + | == What to do with socketpair()-s? == |
| + | |
| + | To restore socketpair we need more help from the server -- the server should create new pair and call criu restore asking it to [[Inheriting FDs on restore|inherit]] one. |
| | | |
| == See also == | | == See also == |