<div dir="ltr"><div><br></div><div><br></div><div><br></div>>- ExecStop command returns before application is actually stopped.<br>>ExecStop must be synchronous, systemd assumes service is stopped when<br>>ExecStop command completes<br> Correct, and yes i finally figure out what service i have to make grid and rdbms dependent so that applicaiton shutdown will be graceful<br><br>>- stopping takes longer then TimeoutStopSec<br> yes i have put a Timeout and it is working correct<br> <br>>- your actual database it still started outside of rdbms.service. The<br>>only process shown in your output is listener, but I would expect rather<br>>more of Oracle there<br><br> database was started by grid.service because when it sees that it was kill by my processes then it will start those services,<br> but that part is solved <br><br>Now I am more eager to know if is it possible to run anything before it kills users processes at shutdown / reboot / halt.<br>or maybe i can be wrong but when shutdown / reboot initiates , it seems it sends a kill signal to all processes parallely.<br>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]).<br>After reading man pages of systemd, as shutdown is being initiated control is being passed from PID 1 to /usr/lib/systemd/systemd-shutdown.<br>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?<div><br></div><div>Thanks a lot for such advice and I have clear my doubts towards systemd with all discussions.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2020 at 12:23 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">17.06.2020 07:46, Kamal Rathi пишет:<br>
>> Please take at least some efforts to format mail so that it can be<br>
>> properly understood. Otherwise I am afraid your mails will simply be<br>
>> ignored.<br>
> <br>
> I am sorry for inconvenience, i will try to follow correct approach<br>
> afterwards while replying<br>
> <br>
>> How RemainAfterExit affects *startup* of services?<br>
> <br>
> The services worked as expected and as i fixed the issue where it was<br>
> using su in script.<br>
> As in background there was SysVinit script which was getting invoked<br>
> when system boot and makes processes falls in users.slice<br>
> So the startup is working perfectly after disabling that SysVinit<br>
> script.<br>
> <br>
>> So I was right. Your programs are running as user services or part of<br>
>> user sessions.<br>
> <br>
> You were absolutely right, I tried to dig into that and find out as it<br>
> was using internally su,<br>
> but now only problem remains is shutdown order.<br>
> As I have created a dependency that rdbms.service should start after<br>
> grid.service which works perfect at boot.<br>
> But when I do shutdown / reboot both services stop simultaneously.<br>
> which i want my grid.service to wait first before rdbms.service will<br>
> stop<br>
> As Type mentioned in services are oneshot.<br>
> <br>
>> dmesg output does not contain any systemd log. Anyway, we already know<br>
>> that your services are not really system services.<br>
> <br>
> So my service is system services, as let me attach cgls output<br>
> <br>
> └─system.slice<br>
> ├─rdbms.service<br>
> │ └─8039 /sarahn9db/db/11.2.0/bin/tnslsnr sarahn9 -inherit<br>
> ├─grid.service<br>
> │ ├─ 5316 /grid/gi/11.2.0/bin/ohasd.bin reboot<br>
> │ ├─ 6159 /grid/gi/11.2.0/bin/cssdagent<br>
> <br>
<br>
The obvious possibilities<br>
<br>
- ExecStop command returns before application is actually stopped.<br>
ExecStop must be synchronous, systemd assumes service is stopped when<br>
ExecStop command completes<br>
<br>
- stopping takes longer then TimeoutStopSec<br>
<br>
- your actual database it still started outside of rdbms.service. The<br>
only process shown in your output is listener, but I would expect rather<br>
more of Oracle there<br>
<br>
Without logs it is impossible to say anything more specific.<br>
<br>
<br>
> On Tue, Jun 16, 2020 at 12:23 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>><br>
> wrote:<br>
> <br>
>> 16.06.2020 07:36, Kamal Rathi пишет:<br>
>>> The fact that you need RemainAfterExit at all hints that processes that<br>
>>> belong to your service are not running as part of service control group.<br>
>>> Knowing how Oracle has traditionally been managed, I suspect that you<br>
>>> perform "su - oracle_owner" or similar to start them in which case all<br>
>>> actual service processes become part of respective user sessions, and<br>
>>> not part of your system services. There is no way to synchronize<br>
>>> stopping of processes/services belonging to different users. They are<br>
>>> completely independent and shutdown for all sessions is initiated in<br>
>>> parallel.<br>
>>><br>
>><br>
>> Please take at least some efforts to format mail so that it can be<br>
>> properly understood. Otherwise I am afraid your mails will simply be<br>
>> ignored.<br>
>><br>
>>> If my theory is correct, the fix would be to actually run your systemd<br>
>>> services as systemd services. If my theory is wrong, provide full from<br>
>>> system boot to shutdown where it could be seen how your services are<br>
>>> started/stopped. Enabling systemd debug log level when doing it<br>
>>> certainly won't harm.<br>
>>><br>
>>><br>
>>><br>
>>> I have incorporated Type=oneshot and remainAfterExit=yes as it was<br>
>> helpful<br>
>>> in startup of services,<br>
>><br>
>><br>
>> How RemainAfterExit affects *startup* of services?<br>
>><br>
>>> but still grid.service are starting up in<br>
>>> user.slice<br>
>><br>
>> So I was right. Your programs are running as user services or part of<br>
>> user sessions.<br>
>><br>
>>> and shutdown was giving the same results<br>
>>> I am attaching debug logs .<br>
>>><br>
>><br>
>> dmesg output does not contain any systemd log. Anyway, we already know<br>
>> that your services are not really system services.<br>
>><br>
>>> On Mon, Jun 15, 2020 at 10:34 AM Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> 15.06.2020 11:01, Kamal Rathi пишет:<br>
>>>>> Hi Team,<br>
>>>>><br>
>>>>> I have two services which are dependent on each other and are working<br>
>>>> fine<br>
>>>>> at boot up but at shutdown / reboot , the processes get killed as<br>
>>>> shutdown<br>
>>>>> got initated.<br>
>>>>><br>
>>>>> Services are running fine in particular order but processes got killed<br>
>> .I<br>
>>>>> have enabled lingering on both users and changed confgiuration in<br>
>>>>> logind.conf to KillUserProcesses=no but still issue is same<br>
>>>>><br>
>>>><br>
>>>> Lingering/KillUserProcesses are relevant only for user services/sessions<br>
>>>> and so far there was no indication you use either.<br>
>>>><br>
>>>>> ##############<br>
>>>>> Systemd service files content are below<br>
>>>>><br>
>>>>> cat /etc/systemd/system/grid.service<br>
>>>>> [Unit]<br>
>>>>> Description=Service to auto start Oracle ASM application<br>
>>>>> Before=rdbms.service<br>
>>>>> After=syslog.target network.target nfs-mountd.service autofs.service<br>
>>>>> systemd-user-sessions.service system.slice<br>
>>>>> [Service]<br>
>>>>> Type=simple<br>
>>>>> TimeoutSec=5min<br>
>>>>> User=grid<br>
>>>>> Group=dba<br>
>>>>> ExecStart=/opt/admin/bin/asm<br>
>>>>> ExecStop=/opt/admin/bin/asm_stop<br>
>>>>> RemainAfterExit=yes<br>
>>>>> [Install]<br>
>>>>> WantedBy=multi-user.target<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> cat /etc/systemd/system/rdbms.service<br>
>>>>> [Unit]<br>
>>>>> Description=Service to auto start Oracle RDBMS application<br>
>>>>> Requires=grid.service<br>
>>>>> After=grid.service syslog.target network.target nfs-mountd.service<br>
>>>>> autofs.service systemd-user-sessions.service system.slice<br>
>>>>> [Service]<br>
>>>>> Type=simple<br>
>>>>> TimeoutSec=5min<br>
>>>>> User=osarahn9<br>
>>>>> Group=dba<br>
>>>>> ExecStart=/opt/admin/bin/rdbms<br>
>>>>> ExecStop=/opt/admin/bin/rdbms_stop<br>
>>>>> RemainAfterExit=yes<br>
>>>>> [Install]<br>
>>>>> WantedBy=multi-user.target grid.service<br>
>>>>><br>
>>>>><br>
>>>>> let me know if my configuration is faulty or what I have missed so that<br>
>>>>> shutdown should be graceful for services and processes will be<br>
>>>>> shutdown with systemd custom service?<br>
>>>>><br>
>>>><br>
>>>> You do not provide enough information (full logs would be certainly much<br>
>>>> more useful than long description) so I can only give educated guess.<br>
>>>><br>
>>>>> I want first rdbms.service should be called and get process stopped<br>
>>>> before<br>
>>>>> grid.services (it seems systemd are killing user.slices processes) and<br>
>> in<br>
>>>>> startup-inverse should be followed .<br>
>>>>> Please help .<br>
>>>>><br>
>>>><br>
>>>> The fact that you need RemainAfterExit at all hints that processes that<br>
>>>> belong to your service are not running as part of service control group.<br>
>>>> Knowing how Oracle has traditionally been managed, I suspect that you<br>
>>>> perform "su - oracle_owner" or similar to start them in which case all<br>
>>>> actual service processes become part of respective user sessions, and<br>
>>>> not part of your system services. There is no way to synchronize<br>
>>>> stopping of processes/services belonging to different users. They are<br>
>>>> completely independent and shutdown for all sessions is initiated in<br>
>>>> parallel.<br>
>>>><br>
>>>> If my theory is correct, the fix would be to actually run your systemd<br>
>>>> services as systemd services. If my theory is wrong, provide full from<br>
>>>> system boot to shutdown where it could be seen how your services are<br>
>>>> started/stopped. Enabling systemd debug log level when doing it<br>
>>>> certainly won't harm.<br>
>>>> _______________________________________________<br>
>>>> systemd-devel mailing list<br>
>>>> <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
>>>> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> systemd-devel mailing list<br>
>>> <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
>>> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> systemd-devel mailing list<br>
>> <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
>> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
>><br>
> <br>
> <br>
> _______________________________________________<br>
> systemd-devel mailing list<br>
> <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
> <br>
<br>
_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div>