Re: [systemd-devel] time-sync.target

[Luke Shumaker]

On Tue, 30 May 2017 11:57:00 -0400,
Pietro Paolini wrote:
> Hi everybody,
> 
> I am trying to configure my systemd to run my service *after* the
> timesyncd service is synchronized with the NTP server, unfortunately
> adding the "After=time-sycd.target" does not work as I can't see any
> change in the behavior - my service is started immediately anyway.
> 
> Reading here https://github.com/systemd/systemd/issues/5097 it looks
> like there is a problem with that target but I am not sure where to
> start from, is it feasible to patch the systemd-timesyncd daemon to
> correct the behavior ?

Yes, this is a problem with timesyncd, and it should eventually be
patched.

The problem with patching it is that without re-thinking something, it
is impossible to have it block time-sync.target without also risking
systemd-timesyncd.service from timing out.

The only solution that I can think of is to have a second helper
process that can't time out that waits for a signal from timesyncd;
and have that process block time-sync.target.  But, the systemd team
hasn't yet decided if this solution is acceptable to them.

So, anyway, I went ahead wrote such a helper program, and a wrapper
for timesyncd that handles sending the signal.

> As alternative I could write my wrapper around the daemon as done in
> the link reporting the issue, both ways I will need to read
> something enlightening on the matter, would you be able to point me
> into the right direction ?

You should be able to install and use the wrapper that I wrote.
There's nothing specific to my use-case about it.  If you install it,
then the "time-sync.target" should "just work" correctly with
timesyncd.

Of course, in the long-term it would be preferable to patch timesyncd,
instead of having to install separate wrapper to fix the behavior.
But for today, it works.

-- 
Happy hacking,
~ Luke Shumaker
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] socket unit refusing connection when JOB_STOP is pending

[Moravec, Stanislav (ERT)]

Uoti, 

yes, it was about Redhat/Centos7 authd (rfc 1413) service, so it was 
the latter - one child process per each connection:

auth@.service:[Unit]
auth@.service:Description=Authd Ident Protocol Requests Server
auth@.service:After=local-fs.target
auth@.service:
auth@.service:[Service]
auth@.service:User=ident
auth@.service:ExecStart=/usr/sbin/in.authd -t60 --xerror --os -E
auth@.service:StandardInput=socket

auth.socket:[Unit]
auth.socket:Description=Authd Activation Socket
auth.socket:
auth.socket:[Socket]
auth.socket:ListenStream=113
auth.socket:Accept=true
auth.socket:
auth.socket:[Install]
auth.socket:WantedBy=sockets.target


regards
Stan 

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

Re: [systemd-devel] socket unit refusing connection when JOB_STOP is pending

[Uoti Urpala]

On Tue, 2017-05-30 at 18:07 +, Moravec, Stanislav (ERT) wrote:
> OK. Understood, thanks much!
> We'll try to follow up on using some parent process (xinetd or something like 
> that).

BTW your problem description wasn't very clear. Is your specific
problem case about socket activation of normal services (the issue
being that if the service has not been started before shutdown it won't
be, but things work if something did start it earlier) or about
Accept=true sockets that start a new service instance from template for
each connection? I'd guess that the latter might be somewhat easier to
support architecturally, though I'm not familiar enough with that to
say for sure.

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

Re: [systemd-devel] socket unit refusing connection when JOB_STOP is pending

[Moravec, Stanislav (ERT)]

OK. Understood, thanks much!
We'll try to follow up on using some parent process (xinetd or something like 
that).
Eventually however, this is a limitation that prohibits using systemd as full 
init
replacement and should be addressed in some way sooner or later, I guess.
Thanks again
Stan

-Original Message-
From: Lennart Poettering [mailto:lenn...@poettering.net] 
Sent: Monday, 29 May, 2017 17:45
To: Moravec, Stanislav (ERT) 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] socket unit refusing connection when JOB_STOP is 
pending

On Tue, 16.05.17 11:28, Moravec, Stanislav (ERT) (stanislav.mora...@hpe.com) 
wrote:

> Hello all,
> 
> I wanted to seek your opinion about correctness of the current behavior
> of socket activated units.
> 
> Let's assume we have socket activated service (for example authd - 
> auth.socket) and 
> some other background service (for the purpose of this test called 
> authtest.service) 
> that needs to connect to the socket service to properly stop itself.
> 
> The authtest defines dependency on auth.socket as expected:
> 
> # cat /usr/lib/systemd/system/authtest.service
> [Unit]
> Description=Test Script to connect auth during shutdown
> After=auth.socket
> Requires=auth.socket
> 
> [Service]
> ExecStart=/bin/true
> ExecStop=/usr/bin/connect_authd
> Type=oneshot
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=multi-user.target
> 
> Yet, authtest doesn't stop correctly (in our test case, the connection just 
> fails,
> not real failure), because auth.socket refuses connections as soon as pending 
> job 
> on auth.socket is JOB_STOP, even if it's not yet time to really stop the 
> unit. 
> 
> The auth.socket:
> May 16 11:23:41 pra0097 systemd[1]: Installed new job auth.socket/stop as 9395
> May 16 11:23:41 pra0097 systemd[1]: Incoming traffic on auth.socket
> May 16 11:23:41 pra0097 systemd[1]: Suppressing connection request on 
> auth.socket since unit stop is scheduled.
> // NOTE the above
> May 16 11:24:44 pra0097 systemd[1]: auth.socket changed listening -> dead
> May 16 11:24:44 pra0097 systemd[1]: Job auth.socket/stop finished, result=done
> May 16 11:24:44 pra0097 systemd[1]: Closed Authd Activation Socket.
> May 16 11:24:44 pra0097 systemd[1]: Stopping Authd Activation Socket.
> 
> The authtest:
> May 16 11:23:41 pra0097 systemd[1]: Installed new job authtest.service/stop 
> as 9337
> May 16 11:23:41 pra0097 systemd[1]: About to execute: /usr/bin/connect_authd
> May 16 11:23:41 pra0097 systemd[1]: Forked /usr/bin/connect_authd as 7051
> May 16 11:23:41 pra0097 systemd[1]: authtest.service changed exited -> stop
> May 16 11:23:41 pra0097 systemd[1]: Stopping Test Script to connect auth 
> during shutdown...
> May 16 11:23:41 pra0097 systemd[7051]: Executing: /usr/bin/connect_authd
> May 16 11:23:41 pra0097 connect_authd[7051]: Tue May 16 11:23:41 CEST 2017
> May 16 11:23:41 pra0097 connect_authd[7051]: COMMAND PID USER   FD   TYPE 
> DEVICE SIZE/OFF NODE NAME
> May 16 11:23:41 pra0097 connect_authd[7051]: systemd   1 root   38u  IPv6  
> 19431  0t0  TCP *:auth (LISTEN)
> May 16 11:23:41 pra0097 connect_authd[7051]: ERROR reading from socket: 
> Connection reset by peer
> May 16 11:23:41 pra0097 connect_authd[7051]: sending message: 80,80
> May 16 11:23:41 pra0097 systemd[1]: Child 7051 belongs to authtest.service
> May 16 11:23:41 pra0097 systemd[1]: authtest.service: control process exited, 
> code=exited status=0
> May 16 11:23:41 pra0097 systemd[1]: authtest.service got final SIGCHLD for 
> state stop
> May 16 11:23:41 pra0097 systemd[1]: authtest.service changed stop -> dead
> May 16 11:23:41 pra0097 systemd[1]: Job authtest.service/stop finished, 
> result=done
> May 16 11:23:41 pra0097 systemd[1]: Stopped Test Script to connect auth 
> during shutdown.
> May 16 11:23:41 pra0097 systemd[1]: authtest.service: cgroup is empty
> 
> 
> The relevant piece of code:
> static void socket_enter_running(Socket *s, int cfd) {
> ...
> /* We don't take connections anymore if we are supposed to shut down 
> anyway */
> if (unit_stop_pending(UNIT(s))) {
> log_unit_debug(UNIT(s), "Suppressing connection request since 
> unit stop is scheduled.");
> ...
> 
> 
> bool unit_stop_pending(Unit *u) {
> ...
> return u->job && u->job->type == JOB_STOP;
> }
> 
> Would not it make sense to still allow connections while the unit is still 
> running? 
> Or maybe for compatibility some boolean could be added to socket unit 
> definition to allow 
> the socket to keep answering connection until it really is stopped.
> 
> If it was not a socket activated unit the 2 services would order and work 
> just fine, 
> so why should socket unit be different?
> 
> Opinions?

This is indeed a shortcoming in systemd's model right now: we don't
permit a start and a stop job to be enqueued for the same unit at the
same time. But to do what you want to do we'd need to permit that: the
service is supposed to stop, but 

[systemd-devel] time-sync.target

[Pietro Paolini]

Hi everybody,

I am trying to configure my systemd to run my service *after* the timesyncd
service is synchronized with the NTP server, unfortunately adding the
"After=time-sycd.target" does not work as I can't see any change in the
behavior - my service is started immediately anyway.

Reading here https://github.com/systemd/systemd/issues/5097 it looks like
there is a problem with that target but I am not sure where to start from,
is it feasible to patch the systemd-timesyncd daemon to correct the
behavior ?

I am not very much familiar with the systemd internals or API but I could
learn the bits I need.

As alternative I could write my wrapper around the daemon as done in the
link reporting the issue, both ways I will need to read something
enlightening on the matter, would you be able to point me into the right
direction ?

Thanks,
P.

-- 


Notice:  This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group. 

 

If you are not the intended recipient, please notify us immediately and 
delete all copies of this message. Please note that it is your 
responsibility to scan this message for viruses. 

 

Fetch and Sizzle are trading names of Speciality Stores Limited and Fabled 
is a trading name of Marie Claire Beauty Limited, both members of the Ocado 
Group.

 

References to the “Ocado Group” are to Ocado Group plc (registered in 
England and Wales with number 7098618) and its subsidiary undertakings (as 
that expression is defined in the Companies Act 2006) from time to time. 
 The registered office of Ocado Group plc is Buildings One & Two, Trident 
Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

[Lennart Poettering]

On Tue, 30.05.17 11:15, Michael Biebl (mbi...@gmail.com) wrote:

> 2017-05-30 10:55 GMT+02:00 NeilBrown :
> > On Tue, May 30 2017, Michael Biebl wrote:
> >
> >> 2017-05-30 0:19 GMT+02:00 NeilBrown :
> >>
> >>> +.B bg
> >>> +option is not supported, and may be stripped from the option list.
> >>
> >> Either systemd is updated to actually strip the bg option or not. The
> >> documentation should reflect that.
> >> I don't think we should be vague about this, as it would only be confusing.
> >
> > It depends on which version of systemd is in use.
> > Even if/when systemd is updated to strip the 'bg', it would not
> > be correct to say "and will be stripped..." as that isn't true for all
> > versions.
> > We could spell it out "and may be stripped from the option list,
> > depending on which version of systemd is installed", but I'm not sure
> > that really helps...
> >  "... and some versions of systemd will strip 'bg' from the option list"
> >  ??
> 
> So far, no version of systemd strips bg from the option list.
> If in version X systemd actually starts stripping bg, we should
> explicitly mention that version in the man page imho.

I figure it's up to the NFS folks to decide on this, but if I were
them I would not mention any version numbers. That just gets out of
date. Instead, document the new behaviour and indicate in the README
file that the documentation assumes systemd with a certain version is
used, and then let the packers figure out the rest, i.e. if they want
to place some kind of weak package version dependency or not.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

[Lennart Poettering]

On Tue, 30.05.17 08:19, NeilBrown (ne...@suse.com) wrote:

> 
> Systemd does not, and will not, support "bg" correctly.
> It has other, better, ways to handle "background" mounting.
> 
> Explain this.
> 
> See also https://github.com/systemd/systemd/issues/6046
> 
> Signed-off-by: NeilBrown 
> ---
>  utils/mount/nfs.man | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index cc6e992ed807..7e76492d454f 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -372,6 +372,21 @@ Alternatively these issues can be addressed
>  using an automounter (refer to
>  .BR automount (8)
>  for details).
> +.IP
> +When
> +.B systemd
> +is used to mount the filesystems listed in
> +.IR /etc/fstab ,
> +the
> +.B bg
> +option is not supported, and may be stripped from the option list.
> +Similar functionality can be achieved by providing the
> +.B x-system.automount

The option is called "x-systemd.automount", i.e. one more "d".

> +option.  This will cause
> +.B systemd
> +to attempt to mount the filesystem when the mountpoint is first
> +accessed, rather than during system boot.  The mount still happens in
> +the "background", though in a different way.

Looks good to me otherwise!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

[Michael Biebl]

2017-05-30 10:55 GMT+02:00 NeilBrown :
> On Tue, May 30 2017, Michael Biebl wrote:
>
>> 2017-05-30 0:19 GMT+02:00 NeilBrown :
>>
>>> +.B bg
>>> +option is not supported, and may be stripped from the option list.
>>
>> Either systemd is updated to actually strip the bg option or not. The
>> documentation should reflect that.
>> I don't think we should be vague about this, as it would only be confusing.
>
> It depends on which version of systemd is in use.
> Even if/when systemd is updated to strip the 'bg', it would not
> be correct to say "and will be stripped..." as that isn't true for all
> versions.
> We could spell it out "and may be stripped from the option list,
> depending on which version of systemd is installed", but I'm not sure
> that really helps...
>  "... and some versions of systemd will strip 'bg' from the option list"
>  ??

So far, no version of systemd strips bg from the option list.
If in version X systemd actually starts stripping bg, we should
explicitly mention that version in the man page imho.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

[NeilBrown]

On Tue, May 30 2017, Michael Biebl wrote:

> 2017-05-30 0:19 GMT+02:00 NeilBrown :
>
>> +.B bg
>> +option is not supported, and may be stripped from the option list.
>
> Either systemd is updated to actually strip the bg option or not. The
> documentation should reflect that.
> I don't think we should be vague about this, as it would only be confusing.

It depends on which version of systemd is in use.
Even if/when systemd is updated to strip the 'bg', it would not
be correct to say "and will be stripped..." as that isn't true for all
versions.
We could spell it out "and may be stripped from the option list,
depending on which version of systemd is installed", but I'm not sure
that really helps...
 "... and some versions of systemd will strip 'bg' from the option list"
 ??

Thanks,
NeilBrown


signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

[Michael Biebl]

2017-05-30 0:19 GMT+02:00 NeilBrown :

> +.B bg
> +option is not supported, and may be stripped from the option list.

Either systemd is updated to actually strip the bg option or not. The
documentation should reflect that.
I don't think we should be vague about this, as it would only be confusing.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel