[systemd-devel] Antw: [EXT] Re: Q: daemon-reload: when and how?

[Ulrich Windl]

>>> Simon McVittie  schrieb am 18.06.2020 um 16:42 in
Nachricht
<27143_1592491364_5EEB7D64_27143_46_1_20200618144233.GA644073@horizon>:
> On Thu, 18 Jun 2020 at 11:01:59 +0200, Jérémy ROSEN wrote:
>> multiple unit files need to work together to make a working environment,
and
>> systemd can't know when all changes are consistent and
>> it is safe to reload. So systemd will want an explicit order from the
user.
> 
> Also, reloading is disruptive and can be "expensive" in terms of resource
> use. If you're making a lot of changes (like an upgrade transaction in
> a package manager like apt or RPM), you probably want to do the entire
> transaction, and then reload *once*.
> 
> dbus‑daemon *does* automatically reload when configuration or service files
> change. People now expect/rely on this, so it's undesirable to change,
> but with hindsight I wish it didn't. I think the fact that systemd
*doesn't*
> automatically reload is partly learning from dbus‑daemon's mistake.
> 
> On Thu, 18 Jun 2020 at 12:43:59 +0200, Ulrich Windl wrote:
>> Is there something like "systemd suggests daemon‑reload" (assuming systemd
>> detects the situation, but does not issue a reload itself)?
> 
> Yes there is:
> 
> $ systemctl status dbus.service
> (... some information here ...)
> $ sudo touch /lib/systemd/system/dbus.service
> $ systemctl status dbus.service
> Warning: The unit file, source configuration file or drop‑ins of
> dbus.service changed on disk. Run 'systemctl daemon‑reload' to reload
> units.
> (... same status information ...)
> 
> In this case I didn't really alter /lib/systemd/system/dbus.service,
> just changed its mtime, but you'd get the same thing from an edit that
> actually matters.

Yes, I've seen such message before, but I had been thinking of something like
a distinct exit status, or a specific query command.

> 
> smcv



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

Re: [systemd-devel] Q: daemon-reload: when and how?

[Simon McVittie]

On Thu, 18 Jun 2020 at 11:01:59 +0200, Jérémy ROSEN wrote:
> multiple unit files need to work together to make a working environment, and
> systemd can't know when all changes are consistent and
> it is safe to reload. So systemd will want an explicit order from the user.

Also, reloading is disruptive and can be "expensive" in terms of resource
use. If you're making a lot of changes (like an upgrade transaction in
a package manager like apt or RPM), you probably want to do the entire
transaction, and then reload *once*.

dbus-daemon *does* automatically reload when configuration or service files
change. People now expect/rely on this, so it's undesirable to change,
but with hindsight I wish it didn't. I think the fact that systemd *doesn't*
automatically reload is partly learning from dbus-daemon's mistake.

On Thu, 18 Jun 2020 at 12:43:59 +0200, Ulrich Windl wrote:
> Is there something like "systemd suggests daemon-reload" (assuming systemd
> detects the situation, but does not issue a reload itself)?

Yes there is:

$ systemctl status dbus.service
(... some information here ...)
$ sudo touch /lib/systemd/system/dbus.service
$ systemctl status dbus.service
Warning: The unit file, source configuration file or drop-ins of
dbus.service changed on disk. Run 'systemctl daemon-reload' to reload
units.
(... same status information ...)

In this case I didn't really alter /lib/systemd/system/dbus.service,
just changed its mtime, but you'd get the same thing from an edit that
actually matters.

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

[systemd-devel] Antw: Re: [EXT] Re: Q: daemon-reload: when and how?

[Ulrich Windl]

>>> Jérémy ROSEN  schrieb am 18.06.2020 um 15:02 in
Nachricht
:

[...]
> (i'm not sure what you mean by "batch" in this context. this is about
> creating a unit, not some
> kind of shell-script-like language)

"batch" is an "at job" that starts immediately...

Regards,
Ulrich


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

Re: [systemd-devel] [EXT] Re: Q: daemon-reload: when and how?

[Jérémy ROSEN]

Le jeu. 18 juin 2020 à 12:44, Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> a écrit :

> >>> Jérémy ROSEN  schrieb am 18.06.2020 um 11:01 in
> Nachricht
>
> <19710_1592470931_5EEB2D93_19710_59_1_CAFvCimXJwvDg0+5W11H0pUh+EHDTGxgbAuAGpG2PL
> gjc0i...@mail.gmail.com>:
> > Le jeu. 18 juin 2020 à 08:53, Ulrich Windl <
> > ulrich.wi...@rz.uni-regensburg.de> a écrit :
> >
> >> Hi!
> >>
> >> I have a question: systemd monitors almost everything it seems to me.
> So I
> >> wonder:
> >> Under what conditions is it necessary to issue a daemon-reload, and why
> >> can't systemd find out itself that a daemon-reload is required?
> >>
> >
> > There are some cases where systemd can detect the proper time for a
> > daemon-reload, and does it implicitely
> > systemd also check mtime of configuration files so it can see when a
> > daemon-reload should be done.
>
> Is there something like "systemd suggests daemon-reload" (assuming systemd
> detects the situation, but does not issue a reload itself)?
>
> Not that I know of...


> >
> > However it is not because a file has been modified that systemd should
> > decide to reload by itself.
> > multiple unit files need to work together to make a working environment,
> > and systemd can't know when all changes are consistent and
> > it is safe to reload. So systemd will want an explicit order from the
> user.
>
> I see (see above).
>
> >
> > So if I think a "manual" daemon-reload is required, is it safe to do it
> >> from within a unit?
> >>
> >
> > Usually, calling daemon-reload from a unit is a sign of bad design or
> > misunderstanding of some tool. What exactly is the problem you are
> > trying to solve ?
> >
> >
> >> I have a "generator-like" type of unit that changes the configuration of
> >> other units. However, as it seems, systemd ignores such changes until I
> use
> >> daemon-reload...
> >>
> >
> > Yes. you need an explicit daemon-reload here.
> > why can't it be a real generator ?
>
> AFAIK generators are quite low-level and have some restrictions. My unit is
> kind of high-level (e.g. it needs all filesystems mounted). Actually I
> started
> with a "normal" generator, but several restriction I can't remember right
> now
> made me change my mind to convert the generator to a "normal" (more or
> less)
> unit.
>
> generators are run very early during boot time so if you need external
filesystems
mounted, that can indeed be a problem.

> >
> > could you use systemd-run or the equivalent dbus API to do what you are
> > trying to do ?
>
> Good question! ;-) Browsing through the manpage I got the impression that
> it's
> systemd's version of "batch" IMHO. I'm unsure whether this has any
> advantage
> for my problem. For dbus I must admit that I have no experience of any kind
> with it...
>
> Well, it has the advantage of not needing a daemon-reload and of getting
rid of the
need to create a config file altogether... you talk directly to the running
instance of systemd

(i'm not sure what you mean by "batch" in this context. this is about
creating a unit, not some
kind of shell-script-like language)


> Regards,
> Ulrich
>
> [...]
>
>

-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

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

[systemd-devel] Antw: [EXT] Re: Q: daemon-reload: when and how?

[Ulrich Windl]

>>> Jérémy ROSEN  schrieb am 18.06.2020 um 11:01 in
Nachricht
<19710_1592470931_5EEB2D93_19710_59_1_CAFvCimXJwvDg0+5W11H0pUh+EHDTGxgbAuAGpG2PL
gjc0i...@mail.gmail.com>:
> Le jeu. 18 juin 2020 à 08:53, Ulrich Windl <
> ulrich.wi...@rz.uni-regensburg.de> a écrit :
> 
>> Hi!
>>
>> I have a question: systemd monitors almost everything it seems to me. So I
>> wonder:
>> Under what conditions is it necessary to issue a daemon-reload, and why
>> can't systemd find out itself that a daemon-reload is required?
>>
> 
> There are some cases where systemd can detect the proper time for a
> daemon-reload, and does it implicitely
> systemd also check mtime of configuration files so it can see when a
> daemon-reload should be done.

Is there something like "systemd suggests daemon-reload" (assuming systemd
detects the situation, but does not issue a reload itself)?

> 
> However it is not because a file has been modified that systemd should
> decide to reload by itself.
> multiple unit files need to work together to make a working environment,
> and systemd can't know when all changes are consistent and
> it is safe to reload. So systemd will want an explicit order from the user.

I see (see above).

> 
> So if I think a "manual" daemon-reload is required, is it safe to do it
>> from within a unit?
>>
> 
> Usually, calling daemon-reload from a unit is a sign of bad design or
> misunderstanding of some tool. What exactly is the problem you are
> trying to solve ?
> 
> 
>> I have a "generator-like" type of unit that changes the configuration of
>> other units. However, as it seems, systemd ignores such changes until I
use
>> daemon-reload...
>>
> 
> Yes. you need an explicit daemon-reload here.
> why can't it be a real generator ?

AFAIK generators are quite low-level and have some restrictions. My unit is
kind of high-level (e.g. it needs all filesystems mounted). Actually I started
with a "normal" generator, but several restriction I can't remember right now
made me change my mind to convert the generator to a "normal" (more or less)
unit.

> 
> could you use systemd-run or the equivalent dbus API to do what you are
> trying to do ?

Good question! ;-) Browsing through the manpage I got the impression that it's
systemd's version of "batch" IMHO. I'm unsure whether this has any advantage
for my problem. For dbus I must admit that I have no experience of any kind
with it...

Regards,
Ulrich

[...]

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

Re: [systemd-devel] Q: daemon-reload: when and how?

[Jérémy ROSEN]

Le jeu. 18 juin 2020 à 08:53, Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> a écrit :

> Hi!
>
> I have a question: systemd monitors almost everything it seems to me. So I
> wonder:
> Under what conditions is it necessary to issue a daemon-reload, and why
> can't systemd find out itself that a daemon-reload is required?
>

There are some cases where systemd can detect the proper time for a
daemon-reload, and does it implicitely
systemd also check mtime of configuration files so it can see when a
daemon-reload should be done.

However it is not because a file has been modified that systemd should
decide to reload by itself.
multiple unit files need to work together to make a working environment,
and systemd can't know when all changes are consistent and
it is safe to reload. So systemd will want an explicit order from the user.

So if I think a "manual" daemon-reload is required, is it safe to do it
> from within a unit?
>

Usually, calling daemon-reload from a unit is a sign of bad design or
misunderstanding of some tool. What exactly is the problem you are
trying to solve ?


> I have a "generator-like" type of unit that changes the configuration of
> other units. However, as it seems, systemd ignores such changes until I use
> daemon-reload...
>

Yes. you need an explicit daemon-reload here.
why can't it be a real generator ?

could you use systemd-run or the equivalent dbus API to do what you are
trying to do ?


>
> (systemd-228-157.9.1.x86_64 of SLES12)
>

Ouch that's old...
Hopefully there are not too many missing features I'm used to have in
there...

Regards
Jeremy

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


-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

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

Re: [systemd-devel] Systemd killed processes of custom services instead of graceful shutdown

[Kamal Rathi]

>- ExecStop command returns before application is actually stopped.
>ExecStop must be synchronous, systemd assumes service is stopped when
>ExecStop command completes
   Correct, and yes i finally figure out what service i have to make
grid and rdbms dependent so that applicaiton shutdown will be graceful

>- stopping takes longer then TimeoutStopSec
   yes i have put a Timeout and it is working correct

>- your actual database it still started outside of rdbms.service. The
>only process shown in your output is listener, but I would expect rather
>more of Oracle there

 database was started by grid.service because when it sees that it was
kill by my processes then it will start those services,
 but that part is solved

Now I am more eager to know if is it possible to run anything before it
kills users processes  at shutdown / reboot / halt.
or maybe i can be wrong but when shutdown / reboot initiates , it seems it
sends a kill signal to all processes parallely.
I tried to capture ps -efj when shutdown initiates and I have seen few bash
sessions get into defunct state(systemd-user-sessions stop [maybe this has
been called]).
After reading man pages of systemd, as shutdown is being initiated control
is being passed from PID 1 to /usr/lib/systemd/systemd-shutdown.
Can I create any dependency in my custom service so that before sending
kill signals to processes or stopping users sessions scope at shutdown /
reboot / halt / poweroff?

Thanks a lot for such advice and I have clear my doubts towards systemd
with all discussions.

On Wed, Jun 17, 2020 at 12:23 AM Andrei Borzenkov 
wrote:

> 17.06.2020 07:46, Kamal Rathi пишет:
> >> Please take at least some efforts to format mail so that it can be
> >> properly understood. Otherwise I am afraid your mails will simply be
> >> ignored.
> >
> >I am sorry for inconvenience, i will try to follow correct
> approach
> > afterwards while replying
> >
> >> How RemainAfterExit affects *startup* of services?
> >
> >   The services worked as expected and as i fixed the issue where it
> was
> > using su in script.
> >   As in background there was SysVinit script which was getting
> invoked
> > when system boot and makes processes falls in users.slice
> >   So the startup is working perfectly after disabling that SysVinit
> > script.
> >
> >> So I was right. Your programs are running as user services or part of
> >> user sessions.
> >
> >  You were absolutely right, I tried to dig into that and find out as
> it
> > was using internally su,
> >  but now only problem remains is shutdown order.
> >  As I have created a dependency that rdbms.service should start after
> > grid.service which works perfect at boot.
> > But when I do shutdown / reboot both services stop simultaneously.
> > which i want my grid.service to wait first before rdbms.service will
> > stop
> > As Type mentioned in services are oneshot.
> >
> >> dmesg output does not contain any systemd log. Anyway, we already know
> >> that your services are not really system services.
> >
> > So my service is system services, as let me attach cgls output
> >
> > └─system.slice
> >  ├─rdbms.service
> >  │ └─8039 /sarahn9db/db/11.2.0/bin/tnslsnr sarahn9 -inherit
> >  ├─grid.service
> >  │ ├─  5316 /grid/gi/11.2.0/bin/ohasd.bin reboot
> >  │ ├─  6159 /grid/gi/11.2.0/bin/cssdagent
> >
>
> The obvious possibilities
>
> - ExecStop command returns before application is actually stopped.
> ExecStop must be synchronous, systemd assumes service is stopped when
> ExecStop command completes
>
> - stopping takes longer then TimeoutStopSec
>
> - your actual database it still started outside of rdbms.service. The
> only process shown in your output is listener, but I would expect rather
> more of Oracle there
>
> Without logs it is impossible to say anything more specific.
>
>
> > On Tue, Jun 16, 2020 at 12:23 AM Andrei Borzenkov 
> > wrote:
> >
> >> 16.06.2020 07:36, Kamal Rathi пишет:
> >>> The fact that you need RemainAfterExit at all hints that processes that
> >>> belong to your service are not running as part of service control
> group.
> >>> Knowing how Oracle has traditionally been managed, I suspect that you
> >>> perform "su - oracle_owner" or similar to start them in which case all
> >>> actual service processes become part of respective user sessions, and
> >>> not part of your system services. There is no way to synchronize
> >>> stopping of processes/services belonging to different users. They are
> >>> completely independent and shutdown for all sessions is initiated in
> >>> parallel.
> >>>
> >>
> >> Please take at least some efforts to format mail so that it can be
> >> properly understood. Otherwise I am afraid your mails will simply be
> >> ignored.
> >>
> >>> If my theory is correct, the fix would be to actually run your systemd
> >>> services as systemd services. If my theory is wrong, provide full from
> >>> system boot to shutdown where it could be 

[systemd-devel] Q: daemon-reload: when and how?

[Ulrich Windl]

Hi!

I have a question: systemd monitors almost everything it seems to me. So I 
wonder:
Under what conditions is it necessary to issue a daemon-reload, and why can't 
systemd find out itself that a daemon-reload is required?
So if I think a "manual" daemon-reload is required, is it safe to do it from 
within a unit?
I have a "generator-like" type of unit that changes the configuration of other 
units. However, as it seems, systemd ignores such changes until I use 
daemon-reload...

(systemd-228-157.9.1.x86_64 of SLES12)

Regards,
Ulrich



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