Re: [systemd-devel] Samba Config Reload

2022-04-09 Thread Leon Fauster

Am 09.04.22 um 10:00 schrieb Yolo von BNANA:

--- Original Message ---
On Friday, April 8th, 2022 at 13:49, Lennart Poettering 
 wrote:


This could be done better. Plugging in just a "kill" here, means the
reload is async. i.e. "systemctl reload" will basically return
immediately without the reload being complete, thus subsequent
commands can't rely the new config is already in place.




It's typically nicer to invoke some synchronous command from
ExecReload=.



Can you please explain this in more Detail?

What does this mean: " "systemctl reload" will basically return
immediately without the reload being complete"?

And what is an Example for an synchronous command for ExecReload=




It seems that killing with USR1|USR2|HUP is commonly used:

$ grep -R ExecReload /usr/lib/systemd/|grep -v kill|wc -l
19
$ grep -R ExecReload /usr/lib/systemd/|grep kill|wc -l
27

Following statement is from
$ man 8 smbd

  Instead of sending a SIGHUP signal, a request to reload
  configuration file may be sent using smbcontrol(1) program.

albeit beforehand they suggest SIGHUP.

--
Leon









Re: [systemd-devel] Samba Config Reload

2022-04-09 Thread Wols Lists

On 09/04/2022 09:00, Yolo von BNANA wrote:

Can you please explain this in more Detail?

What does this mean: " "systemctl reload" will basically return
immediately without the reload being complete"?

And what is an Example for an synchronous command for ExecReload=

Do you understand the difference between "synchronous" and 
"asynchronous"? The words basically mean "aligned in time" and "without 
timed alignment".


Think of writing to files. In the old days of MS-DOS et al, when your 
program called "write", the CPU went off, saved the data to disk, and 
returned to your program. That's "synchronous", all nicely ordered in 
time, and your program knew the data was safe.


Now, when your linux program calls write, linux itself replies "got it", 
and your program goes off knowing that something else is going to take 
care of actually saving the data to disk - that's "asynchronous". Except 
that sometimes the program needs to know that the data HAS been safely 
squirreled away (hence all these fsync calls).


So when systemd calls ExecReload *A*synchronously, it goes off and fires 
off a load more stuff, knowing that the ExecReload IS GOING (future 
tense) to happen. What the previous poster wanted was a synchronous 
ExecReload, so that when systemd goes off do the next thing, the 
ExecReload HAS ALREADY HAPPENED (past tense). (Which in general is a bad 
thing because it *seriously* knackers performance).


Cheers,
Wol


Re: [systemd-devel] Starting one service when another one starts

2022-04-09 Thread Kevin P. Fleming
This sort of behavior has been a long-standing desire of many systemd
users, and you can find probably thousands of blog/forum/SO posts
about it. As Andrei said, the names of the dependencies in systemd
units might appear to be the behavior you want, but they aren't.

If you have a situation where service B must always be running when
service A is running, and never when service A is not running, a
combination of "Upholds" and "PropagatesStopTo" will do that, although
you'll need very recent systemd to have these available.

On Sat, Apr 9, 2022 at 1:17 AM Andrei Borzenkov  wrote:
>
> On 08.04.2022 23:35, Nick Howitt wrote:
> > Sorry, for the delay. Big internet outage.
> >
> > On 08/04/2022 15:15, Andrei Borzenkov wrote:
> >>
> >> On 08.04.2022 14:54, Nick Howitt wrote:
> >>> Hi,
> >>> I apologise if this is not the right place for user help. If it is not,
> >>> please point me to the best place.
> >>>
> >>> I am trying to start a service (clearshare-scheduler) when another
> >>> service (siad) starts. Clearshare-scheduler is an odd service. When you
> >>> start it it may run for ages (days+) or it may terminate immediately so
> >>> I have set it up as a oneshot:
> >>>
> > clearshare-scheduler.service
> >>> [Unit]
> >>> Description=Clearshare Scheduler
> >>> PartOf=siad.service
> >>> After=siad.service
> >>>
> >>> [Service]
> >>> Type=oneshot
> >>> Environment="TERM=dumb"
> >>> ExecStartPre=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
> >>> ExecStartPre=-/usr/bin/echo "$(/usr/bin/date) Starting scheduler from
> >>> systemd" >> /var/log/scheduler.log
> >>> ExecStart=/usr/sbin/clearshare-scheduler.sh > /dev/null
> >>> ExecStop=-/usr/bin/killall -15 -q /usr/sbin/clearshare-scheduler.sh
> >>>
> >>> [Install]
> >>> WantedBy=multi-user.target
> >>>
> >>> The siad service looks like:
> >>>
> > siad.service
> >>> [Unit]
> >>> Description=Siad
> >>> After=syslog.target network.target clearsync.service
> >>>
> >>> [Service]
> >>> Type=simple
> >>> OOMScoreAdjust=500
> >>> PIDFile=/var/run/siad.pid
> >>> EnvironmentFile=/etc/sysconfig/siad
> >>> Environment="SIA_DATA_DIR=/var/lib/siad-data"
> >>> ExecStartPre=-/usr/bin/killall -15 -q clearshare-scheduler.sh
> >>> ExecStartPre=-/usr/bin/rm -f /var/run/siad.pid
> >>> ExecStart=/usr/bin/siad $EXTRA_ARGS
> >>> ExecStop=/usr/bin/siac stop
> >>> WorkingDirectory=/var/lib/sia/
> >>> ExecStartPost=/usr/bin/sh -c 'umask 022; /usr/bin/pgrep siad >
> >>> /var/run/siad.pid'
> >>>
> >>> [Install]
> >>> WantedBy=multi-user.target
> >>>
> >>
> >> You do not show actual unit names which makes it rather difficult to 
> >> follow.
> > Done. See above
> >>
> >>> A "systemctl show clearshare-scheduler" lists the PartOf=siad.service as
> >>> one of its properties but, in reverse, "systemctl show siad" does not
> >>> list the corresponding ConsistsOf property.
> >>>
> >>> When I start siad, nothing happens to the clearshare-scheduler service.
> >>
> >> Why do you expect to happen? There is no Wants or Requires in the unit
> >> that is /probably/ siad.service so request to start siad.service will
> >> not pull in any additional units.
> > Perhaps I have misunderstood, but from the documentation I understood
> > you could PartOf in force (in this case) clearshare-scheduler.service to
> > respond when siad.service was stopped or started. Have I misunderstood
> > the docs? I am hoping to not do any changes to the siad.service.
> >
>
> Documentation for PartOf says "limited to stopping and restarting of
> units". Nothing about "starting". PartOf complements normal startup
> dependencies, not replaces them. And yes, this is confusing, as are the
> names of almost any systemd dependency which mean something entirely
> different from what these names imply in English.
>
> You can add WantedBy=siad.service to [Install] section of
> clearshare-scheduler.service. In general you can always extend Wants by
> manually creating necessary links. This does not require you to edit
> unit definition itself. You can also create drop-in (although I am not
> sure whether they are already supported in your systemd version).
>
> > As an alternative, which does affect the siad.service, is there any way
> > I can run the clearshare-scheduler.sh script from the siad.service? I
> > have tried starting it as a ExecStartPost, but it does not appear to
> > work if the script does not exit immediately. If it runs for a while,
> > then systemd says siad has failed to start.
>
> You can increase TimeoutStartSec.
>
> > I've tried launching it with
> > ExecStartPost=-/usr/sbin/clearshare-scheduler.sh
>
> "-" affects command that completed with failure status, in your case
> command does not complete so this does not have any effect.
>
> > and
> > ExecStartPost=-/usr/sbin/clearshare-scheduler.sh &
> > and
> > ExecStartPost=-/usr/bin/nohup /usr/sbin/clearshare-scheduler.sh &
> >
>
> sytsemd is not shell, what made you think this would work? If you want
> to use shell syntax, you need to invoke shell
>
> /bin/sh 

Re: [systemd-devel] Samba Config Reload

2022-04-09 Thread Yolo von BNANA
--- Original Message ---
On Friday, April 8th, 2022 at 13:49, Lennart Poettering 
 wrote:

> This could be done better. Plugging in just a "kill" here, means the
> reload is async. i.e. "systemctl reload" will basically return
> immediately without the reload being complete, thus subsequent
> commands can't rely the new config is already in place.
> 

> It's typically nicer to invoke some synchronous command from
> ExecReload=.


Can you please explain this in more Detail?

What does this mean: " "systemctl reload" will basically return
immediately without the reload being complete"?

And what is an Example for an synchronous command for ExecReload=



signature.asc
Description: OpenPGP digital signature