[systemd-devel] Question on service related notifications

[Pathangi Janardhanan]

Hi,

 I would like to monitor for systemd related service notifications (for
e.g. service started, service ready, service stopped or service failed etc.)

 I am trying to look through the sd-bus notification, and was looking at
the org.freedesktop.systemd1.manager and the subscribe method? Is this the
method to be used for receiving this type of notifications, and if I use
this would that program receive the correspodning notification through the
UnitNew() and unitremoved(0 signals?

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Facility to debug/trace services especially at system startup time

[Pathangi Janardhanan]

Hi All,

 What is the best option to do some debug/analysis of the system and the
services started by systemd during initial bootup?

 I would like to use tools like perf and strace etc. on some of the
services. I could do this by starting the service manually but would like
to have all the services that start at bootup and was wondering if there is
a way for me to do this sort of thing, just for the initial boot up time.

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] restart vs. stop/start

[Pathangi Janardhanan]

Hi,

 Internally systemd, does differentiate between

 stop - start
and
  restart

 because when you use restart, it preserves any FDs that were saved across
the stop and provides it to the start, but does not do the same thing, when
the user explictly does a stop/start.

 I think it would be nice if the service was aware of this so that it can
know the difference between a fresh start, versus restart with no resources
saved. It may not mean anything different for some services, but may mean
different things for some service.

Thanks
Jana


On Sun, May 22, 2016 at 2:19 PM, Christian Boltz 
wrote:

> Hello,
>
> Am Sonntag, 22. Mai 2016, 21:48:02 CEST schrieb Reindl Harald:
> > Am 22.05.2016 um 21:03 schrieb Christian Boltz:
> > > I'm already using ExecReload= to reload the profiles (works fine),
> > > and hope all users actually read the documentation and use reload
> > > (and avoid restart).
> > >
> > > Please read the paragraph above the ^^^ marker again.
> > > The problem is what happens when someone accidently uses restart
> >
> > when someone is using the wrong command - well, he is using the wrong
> > command - that's it - acting as root implies someone knows what he is
> > doing
>
> Did you ever hear of "better safe than sorry"?
>
> *Every* admin will make an error sooner or later, so it's good style to
> limit the damage as good as possible.
>
> In case of AppArmor, the good old initscripts basically mapped "restart"
> to "reload", so there was no risk of using the "wrong" command because
> both worked in a sane way (= reloading the profiles).
>
> > and something which don't surive a restart in a sane way is
> > broken from the very begin
>
> [first version of my answer censored]
>
> I hope not everybody on this mailinglist thinks that being different
> means being broken ;-)
>
> BTW: You still didn't answer Andrei's question...
>
>
> Regards,
>
> Christian Boltz
> --
> LGTM? There is a special place in hell for regular expressions.
> [ewindisch on https://github.com/docker/docker/pull/19069]
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] socket activation systemd holding a reference to an accepted socket

[Pathangi Janardhanan]

Hi,
 Please see this thread
http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/35437, and for
that usecase,  the suggestion to do shutdown did work fine, and with that I
was able to handle this case.

 At that time, the other request I had was if sd_pid_notify_with_fds or
equivalent could be enhanced to explictly ask systemd to forgot some FDs,
as I felt that would be useful in situations where systemd is being used as
FD store, and the FDs that are being stored may not always support shutdown
type of activity.


>
>> Normally one would solve this by inserting shutdown(fd, SHUT_RDWR) at
>> the right place, since that *really* terminates the connection,
>> regardless if anyone else has an fd open still. Is that an option
>> here?
>>
>
> I didn't actually try that myself but that was the 2nd thing that I
> suggested when I got the original problem report and the developer who
> reported the problem told me that it didn't work.
>
>>
>> Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd default target

[Pathangi Janardhanan]

Hi,

 I have some services configured with the above, Restart=on-failure and
StartLimitInterval/StartLimitBurst and also StartLimitAction with reboot.

 The problem I am trying to look at is, how to get out of a continuous
reboot cycle, if one of the services is failing. That is why I was looking
for any options where systemd can have its default target changed to
recover or something equivalent, if the system is undergoing repeated
reboots within a certain interval?

 I may be able to do this by writing a separate unit/service for this, but
was wondering if there was any already inbuilt mechanism to prevent
continuous  reboot cycle from a mis-behaving service/unit, which is
configured for reload on failure?

Thanks
Jana


On Sat, Feb 13, 2016 at 2:48 AM, Lennart Poettering <lenn...@poettering.net>
wrote:

> On Fri, 12.02.16 20:58, Pathangi Janardhanan (path.j...@gmail.com) wrote:
>
> > Hi All,
> >
> >  The default target is usually set to multi-user or someother equivalent
> > target. Is there any way in systemd that I can say something like
> >
> > " If the system is reloaded n number of times within the last x second",
> > than set the default target to recover or emergency mode etc.?
> >
> >  Basically I am looking for recovering from a failing unit/service that
> is
> > forcing the system to reboot, and that is going in a cycle?
>
> You may configure whether a unit shall be automatically restarted with
> Restart=on-failure. You may put a limit on it with StartLimitInterval=
> and StartLimitBurst=. You may configure what shall happen if the limit
> is hit with StartLimitAction=, which includes making the system reboot.
>
> See the systemd.service and systemd.unit man pages.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd default target

[Pathangi Janardhanan]

Hi All,

 The default target is usually set to multi-user or someother equivalent
target. Is there any way in systemd that I can say something like

" If the system is reloaded n number of times within the last x second",
than set the default target to recover or emergency mode etc.?

 Basically I am looking for recovering from a failing unit/service that is
forcing the system to reboot, and that is going in a cycle?

Thanks
jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Dependencies on targets

[Pathangi Janardhanan]

Hi All,

 I have a target t1, which has three services associated with it, t11, t12
and t13. The service dependencies After etc. I have in the individual t11,
t12 and t13 unit files

 I have another target t2, which has two service associated with it t21,
t22. I want all units associated with target t2 to start only after all
units in target t1 are ready.

 So in t2.target , i have
 Requires=t1.target
 After=t1.target

 and in the t21.service and t22.service, I have
 Wants=t2.target

and in Install section
 WantedBy=t2.target

 But with this I find all the services that I want associated with t2,
start right along with the services in t1.

 If I change the t21.service and t22.service to include

 Requires=t2.target
 After=t2.target

 Things work as expected, i.e. all services in t1.target get started and
ready before services t21 and t22 are started

 So I would like to know if this is the correct way to order the dependency
on the target, because if say After=t2.target, though it is actually (at
least my intention) is that this service is associated with t2.target.

I have also attached all the service and target files for reference.

Thanks
Jana


t1.target
Description: Binary data


t2.target
Description: Binary data


t11.service
Description: Binary data


t12.service
Description: Binary data


t13.service
Description: Binary data


t21.service
Description: Binary data


t22.service
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Can one service receive SD_NOTIFY (Ready) message of another service?

[Pathangi Janardhanan]

Hi All,

 The use case I have is following:

 I have a service B, which for its operation depends on Service A. Using
systemd feature, I can make systemd start service B after service A has
indicated ready.

 The issue is service B also does a lot of initialization which is
independent of service A (which also has length initialization code). After
that initialization it needs to know of service A availability, before
service B can declare itself ready.

 I see two choices:

1. Use systemd and have it start service B after service A is fully ready,
even if that means that the service B intialization is not being done in
parallel

2. Let systemd start service A and B together, and have some specific
messaging/mechanism from service A and B

 The third option I was looking for but which I could not find, was to

 have systemd start both independently, and then have service B query/wait
on systemd service till service A sends a SD_NOTIFY with ready message?

 is something like that possible, or is option 2 the best way for me to
proceed?

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Difference between restart versus stop-start

[Pathangi Janardhanan]

Hi,

 I am using sd_notify_pid_with_fds and subsequently sd_notify_fds to store
and receive fds from systemd.

 Systemd differentiates between

 systemctl restart   -> Where it stops and starts the service, but
maintains the fd stored above

 whereas if I do systemctl stop  and then start, the fds are
cleaned out.

 This works well for me, but my question is that apart from the fds, the
service also stores local state and tries to restore them on start, and i
need the same logic for that data also. i.e. if the service is being
restarted than it stores that data otherwise it deletes and flsuhes them
out.

 So my question is, is there any way for the service to know when it is
being stopped that it is done for a restart versus stop command?

 Without that it seems difficult for the service to make the determination
to maintain/restore state or flush/init state?

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd to as a FD Store to provide service while package upgrade

[Pathangi Janardhanan]

Hi Lennart,

 Thanks.

 Yes, shutdown does take care of removing the fds from the systemd context.

 The solution seems fine and it is working good. Thanks for the help.

Thanks
Jana



On Tue, Jan 12, 2016 at 12:24 PM, Lennart Poettering <lenn...@poettering.net
> wrote:

> On Wed, 06.01.16 13:05, Pathangi Janardhanan (path.j...@gmail.com) wrote:
>
> > Currently in my package scripts I am doing a service stop and start.
> > But when I need to do an upgrade, if I do a service stop, systemd clears
> > all the fds. So would that mean that my package scripts would have to:
> >
> >  a. In case of upgrade, do not call stop, but ensure that the fds are
> > saved, and then after the upgrade, ensure that we call a service restart?
> > Is it safe to remove/change the service files while it is executing?
>
> Well, my recommendation would be to push the fds to systemd as soon as
> you received them, so that systemd always has them. Then, a simple
> "systemctl restart" is sufficient to restart the daemon while the fds
> stay open.
>
> By pushing the fds to PID 1 right-away when you acquire them you get a
> certain level of stability regarding crashes: you can crash any time,
> and systemd will allow you to continue if your daemon is restarted
> after the crash right where you left off...
>
> An alternative to pushing the fds to PID 1 right-away is to do so when
> your daemon shuts down. Note that it doesn't really matter if your
> daemon is restarted or shut down in this case, all fds you pass to
> systemd will be closed by systemd should your service just be stopped
> and not actually restarted...
>
> >  b. In case the service package is being removed, do a normal stop in the
> > scripts
> >
> >Is this approach o.k., or are there other recommendations?
>
> This should be fully sufficient.
>
> >
> > 2. I had also indicated in the other thread, that systemd does not seem
> to
> > clear the fds, even if the fds are actually closed. So to repeat, the
> > sequence is
>
> See other thread, shutdown() is your friend.
>
> > 3. Is Systemd intended for this type of fd store for upgrade handling,
> and
> > if others have any other approaches or limitations with this approach,
> that
> > would be welcome?
>
> Yes, we added it explicitly for purposes like this. journald has been
> made restartable using this logic. It needs to deal with many incoming
> client connections, and get them passed back should it die
> or get restarted. In journald we send the connection fds to PID 1
> right after we got them via accept().
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Using Systemd "FD Store" facilitiy

[Pathangi Janardhanan]

Hi,

 I had previously sent a mail on this but got no response, so wanted to
check again.

 I am trying to use systemd as a way to store and restore the FDs used by a
service, so that the service can provide continuation of service during an
upgrade. for the purpose of trying it out, I am using a simple TCP echo
server as my service

 The issues I see are :

1. I store the fds using sd_pid_notify_with_fds, and then do a systemctl
restart of the service. Then I use sd_listen_fds and get all the fds back
and the service continues without disturbance. But the problem is

a.  systemd continues to hold all these fds, so now if my service is done
with the fd and closes the connection, this is not getting through to the
client, as systemd continues to have this fd

b. Even if the client closes the connection, my service gets it and closes
the connection but systemd still holds on to this fd.

 so in essence once I store the fd with systemd using
sd_pid_notify_with_fds, they do not go away untill I do a systemctl stop of
my service

This is making it difficult to use this service in the intended way. It
would be nice
if on sd_listen_fds, the sytemd passes all fds back to the service and
internally cleared its state, so that only the service has the fds. (this
is ofcourse only for
those fds that the service had previously send in sd_pid_notify_with_fds,
the other fds that the service gets as part of socket activation would
continue to be held in systemd also.)

Let me know if this sounds correct, or am I mis-understanding the way this
service is to be used.

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Using systemd to as a FD Store to provide service while package upgrade

[Pathangi Janardhanan]

Hi,

I had a previous thread on some issues in using sd_pid_notify_with_fds, but
started this as a separate thread, as this is not just about that call,
which anyway seems to be because I am using a older version.

 I am trying to provide continuous service to connected clients (over TCP
socket) while my service package is being upgraded.

 In regard to that I had a few questions on what is the best way to handle
this:

1. When I initiate the upgrade, I have my service store the fds into
systemd using the call sd_pid_notify_with_fds.

Currently in my package scripts I am doing a service stop and start.
But when I need to do an upgrade, if I do a service stop, systemd clears
all the fds. So would that mean that my package scripts would have to:

 a. In case of upgrade, do not call stop, but ensure that the fds are
saved, and then after the upgrade, ensure that we call a service restart?
Is it safe to remove/change the service files while it is executing?

 b. In case the service package is being removed, do a normal stop in the
scripts

   Is this approach o.k., or are there other recommendations?

2. I had also indicated in the other thread, that systemd does not seem to
clear the fds, even if the fds are actually closed. So to repeat, the
sequence is

   a. First invocation of the service, start servicing the clients, and
then store the fds in systemd
b. Do a restart, the new instance gets these fds, and continues to
service the clients. things work o.k.
c. the client closes the connection, the service also closes all its
state and connection about this client.
d. I do another restart and since at this time there is no client fds,
the service does not store anything with  systemd
e. In the new invocation of my service, in sd_listen_fds, I still get
the older fd that I had stored.
f. currently in my service, this is not a problem, since when my
service tries to do a select on these fds, it gets a notification and then
closes out the fd.

But this behaviour could cause some issues later on, and also since
systemd does not seem to ever let go of the fds, If i continue to do many
restarts, would the set of fds build up to a large set in systemd?

What is the correct approach to handle this situation?

3. Is Systemd intended for this type of fd store for upgrade handling, and
if others have any other approaches or limitations with this approach, that
would be welcome?

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Pathangi Janardhanan]

Hi Daniel,
 >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.

  Yes, it works without the connect thank you. Maybe I will try to see if I
can locally move to the latest version.

>b) Pass your own PID to sd_pid_notify_with_fds()

 I had tried that before and it does not work, looks like even though my
nfds is never zero, the have_pid flag is causing the issue,
and to set that flag I have to pass a PID that is not my process PID?

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Using systemd to as a FD Store to provide service while package upgrade

[Pathangi Janardhanan]

Hi,

 To add, another issue with systemd holding on to the service fds is that
if after a restart, the service does a sd_listen_fds gets the saved fds and
starts providing the service. Later on if the service decides to close a
connection than it performs a close, but the remote client is not going to
see the close, since systemd is still holding on to that fd? So we need to
have a mechanism to be able to tell systemd to
"forgot" all the fds that it is holding on behalf of this service (except
for the fds that are coming through the .socket socket invocation)

Thanks
Jana


On Wed, Jan 6, 2016 at 1:05 PM, Pathangi Janardhanan <path.j...@gmail.com>
wrote:

> Hi,
>
> I had a previous thread on some issues in using sd_pid_notify_with_fds,
> but started this as a separate thread, as this is not just about that call,
> which anyway seems to be because I am using a older version.
>
>  I am trying to provide continuous service to connected clients (over TCP
> socket) while my service package is being upgraded.
>
>  In regard to that I had a few questions on what is the best way to handle
> this:
>
> 1. When I initiate the upgrade, I have my service store the fds into
> systemd using the call sd_pid_notify_with_fds.
>
> Currently in my package scripts I am doing a service stop and start.
> But when I need to do an upgrade, if I do a service stop, systemd clears
> all the fds. So would that mean that my package scripts would have to:
>
>  a. In case of upgrade, do not call stop, but ensure that the fds are
> saved, and then after the upgrade, ensure that we call a service restart?
> Is it safe to remove/change the service files while it is executing?
>
>  b. In case the service package is being removed, do a normal stop in the
> scripts
>
>Is this approach o.k., or are there other recommendations?
>
> 2. I had also indicated in the other thread, that systemd does not seem to
> clear the fds, even if the fds are actually closed. So to repeat, the
> sequence is
>
>a. First invocation of the service, start servicing the clients, and
> then store the fds in systemd
> b. Do a restart, the new instance gets these fds, and continues to
> service the clients. things work o.k.
> c. the client closes the connection, the service also closes all its
> state and connection about this client.
> d. I do another restart and since at this time there is no client fds,
> the service does not store anything with  systemd
> e. In the new invocation of my service, in sd_listen_fds, I still get
> the older fd that I had stored.
> f. currently in my service, this is not a problem, since when my
> service tries to do a select on these fds, it gets a notification and then
> closes out the fd.
>
> But this behaviour could cause some issues later on, and also since
> systemd does not seem to ever let go of the fds, If i continue to do many
> restarts, would the set of fds build up to a large set in systemd?
>
> What is the correct approach to handle this situation?
>
> 3. Is Systemd intended for this type of fd store for upgrade handling, and
> if others have any other approaches or limitations with this approach, that
> would be welcome?
>
> Thanks
> Jana
>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Pathangi Janardhanan]

Hi,
>> ret = sd_pid_notify_with_fds(0, 0, "FDSTORE=1\n", (const int *) fd,
>>num_fd);

> Is "fd" a single fd? If so you need to pass this as  of course...

No, fd is a int array, which holds num_fd,  "fd" values.

>The FDSTORE=1 line doesn't need to be suffixed with "\n" btw (but it
>doesn't hurt if you do...)
>It might be worth strace'ing your process to see that the right
>sendmsg() call is issued. If in doubt, strace this specific code
>snippet and paste the sendmsg() line here.

 This is the output of the strace call on this section of the code in the
sd_pid_notify_with_fds, when I try to save the fds.

socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8

sendmsg(8, {msg_name(21)={sa_family=AF_LOCAL,
sun_path="/run/systemd/notify"}, msg_iov(1)=[{"FDSTORE=1\n", 10}],
msg_controllen=40, {cmsg_len=20, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, MSG_NOSIGNAL) = -1 EINVAL
(Invalid argument)

close(8)= 0

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Pathangi Janardhanan]

Hi,


>>  This is the output of the strace call on this section of the code in
>> the sd_pid_notify_with_fds, when I try to save the fds.
>>
>> socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
>>
>> sendmsg(8, {msg_name(21)={sa_family=AF_LOCAL,
>> sun_path="/run/systemd/notify"}, msg_iov(1)=[{"FDSTORE=1\n", 10}],
>> msg_controllen=40, {cmsg_len=20, cmsg_level=SOL_SOCKET,
>> cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, MSG_NOSIGNAL) = -1 EINVAL
>> (Invalid argument)

>Which version of systemd are you running? Does it contain a5bd3c32?

 Sorry forgot to attach the version, here is the version I am using

jana@ctoserver11:~$ systemd --version
systemd 225
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN

And my OS is Ubuntu Wily

jana@ctoserver11:~$ lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 15.10
Release:15.10
Codename:wily

 let me if this is an issue and I have to move to another version?

Thanks
Jana
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Pathangi Janardhanan]

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?

 Can someone point out what should be the correct fix for this to make it
work?
int my_pid_notify_with_fds(pid_t pid, int unset_environment,
char *state, int *fds, unsigned n_fds)
{
struct sockaddr_un saddr;
struct iovec iov;
struct msghdr snd_msg;
struct cmsghdr *cmsg;
const char *e;
int myfd, ret;

saddr.sun_family = AF_UNIX;
e = getenv("NOTIFY_SOCKET");
strncpy(saddr.sun_path, e,sizeof(saddr.sun_path));

myfd = socket(AF_UNIX, SOCK_DGRAM, 0);
   if (connect(myfd, (const struct sockaddr *) , sizeof(saddr)) != 0)
{
return -1;
}

iov.iov_base = (char *)state;
iov.iov_len = strlen (state);

snd_msg.msg_iov = 
snd_msg.msg_iovlen = 1;
snd_msg.msg_name = NULL;
snd_msg.msg_namelen = 0;

snd_msg.msg_controllen = CMSG_SPACE(sizeof(int) * n_fds);
snd_msg.msg_control = malloc(snd_msg.msg_controllen);
cmsg = CMSG_FIRSTHDR(_msg);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
cmsg->cmsg_len = CMSG_LEN(sizeof(int) * n_fds);
memcpy(CMSG_DATA(cmsg), fds, sizeof(int) * n_fds);

ret = sendmsg(myfd, _msg, 0);
close (myfd);
return (ret);
}


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
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

 So how do I make systemd "forgot" the fd or how is this scenario to be
handled?

Thanks
jana


On Tue, Jan 5, 2016 at 1:55 PM, Pathangi Janardhanan <path.j...@gmail.com>
wrote:

> Hi,
>
>
> >>  This is the output of the strace call on this section of the code in
> >> the sd_pid_notify_with_fds, when I try to save the fds.
> >>
> >> socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
> >>
> >> sendmsg(8, {msg_name(21)={sa_family=AF_LOCAL,
> >> sun_path="/run/systemd/notify"}, msg_iov(1)=[{"FDSTORE=1\n", 10}],
> >> msg_controllen=40, {cmsg_len=20, cmsg_level=SOL_SOCKET,
> >> cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, MSG_NOSIGNAL) = -1 EINVAL
> >> (Invalid argument)
>
> >Which version of systemd are you running? Does it contain a5bd3c32?
>
>  Sorry forgot to attach the version, here is the version I am using
>
> jana@ctoserver11:~$ systemd --version
> systemd 225
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN
>
> And my OS is Ubuntu Wily
>
> jana@ctoserver11:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID:Ubuntu
> Description:Ubuntu 15.10
> Release:15.10
> Codename:wily
>
>  let me if this is an issue and I have to move to another version?
>
> Thanks
> Jana
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel