[systemd-devel] Unable to store fds with systemd and reterive it back again

[Daniel Mack]

Hi,

On 01/06/2016 12:07 AM, Pathangi Janardhanan wrote:
> Hi All,
> 
>  After trying a few things out, here are couple doubts that I have.
> 
> 1. I am able to get this to work, if I modify the way the sendmsg is
> being done, here is a temp. function that I wrote in my own service
> to mimic the actions of sd_pid_notify_with_pids and with this I am able
> to store the fds with systemd and reterive it back again on a
> service restart.
> 
>  The only real difference is that I do a connect on the socket before
> doing the sendmsg call, and searching through some stuff on google seems
> to indicate that you need to do connect for unix domain sockets, but not
> sure if that is the right thing to do?

It's only necessary to connect() sockets that are in connection mode
(SOCK_STREAM or SOCK_SEQPACKET), but this one is a SOCK_DGRAM socket.

The reason why this is failing is because your systemd version is too
old. All versions prior to v227 have a bug that causes a miscalculation
of the msg_controllen value of the message header, hence the syscall
rightfully fails. Any chance the Ubuntu people could backport a5bd3c32?
Martin?

As a workaround, you basically have to options:

a) open-code the routine as you did, but you can leave off the connect()
call, that's not needed.

b) Pass your own PID to sd_pid_notify_with_fds().

> 2. The other issue I now have, is that after my service is restarted, I
> am able to reterive this and continue to service the client. But I am
> not able to delete this from the systemd state.
> 
>  The sequence is,
> 1. Start the service, and handle some clients
> 2. On a trigger, store the client fds
> 3. Do a systemctl restart of the service, and the service gets these fds
> in the new invocation

This is intended. systemd holds a reference to the file descriptor you
passed, so it will have it ready for you on each start of the service.
This way, if the task just drops everything on idle, or even if it
crashes, all fds that have been passed over earlier will be restored.

> 4. it handles the client and the client closes the connection
> 5. Now I do another restart of the service, but I still get this fd

This shouldn't happen. If the client closes the connection, systemd
should get EPOLLHUP on the fd and remove it from the set of file
descriptors, hence dropping its reference. Are you sure the client
properly closes its side of the communication?


HTH,
Daniel