Re: [systemd-devel] Script in /usr/lib/systemd/system-shutdown not executed on init 6
Hello, On 11/23/2016 03:52 PM, Reindl Harald wrote: > so why do you strip the whole context and rest of the response? > > what is your exactly problem? > I think my original question on this thread is clear. > it should be no rocket science to define a service, order starting as > needed which ensures at the same time that stop services happens in > the exactly reverse order > It is more than rocket science to have the same behaviour for my SAP system behaviour on RH7 like on RH6. On RH6 I could boot my server. Then a few days after I could manually restart dedicated processes. On the next shutdown, I knew my processes would be cleanly stopped. With RH7, my commands' executions need to be wrapped by systemd service. Otherwise, as L. Poettering said, these daemons are not stopped cleanly at shutdown. This what I have understood. > maybe you should stop looking at old sysv scripts and just start from > scratch and define what you need in a proper systemd unit - for many > things you will find out that a lot of magic from init scripts is not > needed at all > This is what I am trying to do :-) > for me it ssems what you trying to to is wrap everything from a init > script in a native systemd-unit which is wrong from the start in most > cases "trying to wrap everything from init script" is not my overall goal. My over goal is to administer my SAP systems on my new RH7 servers. I have constraints from RH7 and from SAP and from Oracle DB. After reading that there is systemv systemd generator, I thought that I could have all the old functionalities with systemd. It is not the case. Therefore I am trying to find the best compromises to run my SAP systems. This implies understanding what I can do and what I cannot do with systemd. This is why I ask questions like the one on this thread. Regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] unsbubscribe
unsbubscribe mit freundlichen Grüßen Jürgen Sauer -- Jürgen Sauer - automatiX GmbH, +49-4209-4699, juergen.sa...@automatix.de Geschäftsführer: Jürgen Sauer, Gerichtstand: Amtsgericht Walsrode • HRB 120986 Ust-Id: DE191468481 • St.Nr.: 36/211/08000 GPG Public Key zur Signaturprüfung: http://www.automatix.de/juergen_sauer_publickey.gpg ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Started process not attach to its related service.
Hello, On 11/23/2016 07:26 PM, Andrei Borzenkov wrote: > Recent (for suitable definition of "recent") SAP releases are using > sapcontrol framework to start/stop SAP services. So start startsap > actually does, is to make remote procedure call to sapstartsrv which > then starts SAP instance processes. So as long as startsapsrv itself is > launched as separate service, your problem should not happen. This may > offer suitable workaround. You are reporting a useful point. I can not do all my Oracle DB and SAP administration with sapstartsrv. But this can cover a big part of the job as this daemon stay alive even when a whole SAP instance is stopped. I have to test how sapstartsrv preserve cgroup. Thanks a lot for pointing out this :-) -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Script in /usr/lib/systemd/system-shutdown not executed on init 6
Hello, On 11/24/2016 12:22 AM, Lennart Poettering wrote: > In general, while systemd provides a large degree of SysV compat, in > the end we aren't SysV and thus we do not provide 100%. In cases like > this this becomes visible. You are 100% right :-) Right after upgrading my first server, I wrongly assumed that systemv scripts could be migrated easily. I was wrong. Thanks for all the feedbacks you have provided. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Script in /usr/lib/systemd/system-shutdown not executed on init 6
On Thu, 24.11.16 10:59, Benoit SCHMID (benoit.sch...@unige.ch) wrote: > Hello, > > On 11/24/2016 12:22 AM, Lennart Poettering wrote: > > In general, while systemd provides a large degree of SysV compat, in > > the end we aren't SysV and thus we do not provide 100%. In cases like > > this this becomes visible. > > You are 100% right :-) > > Right after upgrading my first server, > I wrongly assumed that systemv scripts > could be migrated easily. > I was wrong. Well, most of them can. It's the exotic ones which can't be that easily. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] after=local-fs not enforced
Hello, We have defined the following sap_XXX.service. It contains the following in [Unit]: ### After=local-fs.target network-online.target ora_lsnr_XXX.service remote-fs.target Wants=ora_lsnr_XXX.service ### Stopping and Starting the service with systemd runs fine. When we reboot, systemd umounts local file systems, before sap_XXX is stopped. This is done although there is After=local-fs.target. What are we missing? Above there is the output with a few substitutions (XXX and YYY). http://pastebin.com/nLJ5Zbgj # systemctl --version systemd 219 Thanks for your answer. -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=local-fs not enforced
Am 24.11.2016 um 16:20 schrieb Benoit SCHMID: We have defined the following sap_XXX.service. It contains the following in [Unit]: ### After=local-fs.target network-online.target ora_lsnr_XXX.service remote-fs.target Wants=ora_lsnr_XXX.service ### Stopping and Starting the service with systemd runs fine. When we reboot, systemd umounts local file systems, before sap_XXX is stopped. This is done although there is After=local-fs.target. What are we missing? Above there is the output with a few substitutions (XXX and YYY). http://pastebin.com/nLJ5Zbgj you *really* should post the whole systemd-unit instead pieces! have you played around with DefaultDependencies? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=local-fs not enforced
Hello, On 11/24/2016 04:42 PM, Reindl Harald wrote: > > you *really* should post the whole systemd-unit instead pieces! > have you played around with DefaultDependencies? Here it is :-) [Unit] Description=SAP XXX After=local-fs.target network-online.target ora_lsnr_XXX.service remote-fs.target Wants=ora_lsnr_XXX.service [Service] EnvironmentFile=/etc/default/sap_XXX User=xxxadm Group=sapsys ExecStart=/sapmnt/XXX/exe/nuc/linuxx86_64/startsap ExecStop=/sapmnt/XXX/exe/nuc/linuxx86_64/stopsap Restart=no TimeoutStopSec=5min TimeoutStartSec=5min Type=forking [Install] WantedBy=multi-user.target Regards, -- _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Benoit Schmid Tel: (+41-22) 379-7209 University of Geneva - Information Technology Division _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=local-fs not enforced
24.11.2016 18:20, Benoit SCHMID пишет: > Hello, > > We have defined the following sap_XXX.service. > It contains the following in [Unit]: > ### > After=local-fs.target network-online.target ora_lsnr_XXX.service > remote-fs.target > Wants=ora_lsnr_XXX.service > ### > > Stopping and Starting the service with systemd runs fine. > > When we reboot, systemd umounts local file systems, > before sap_XXX is stopped. > This is done although there is After=local-fs.target. > > What are we missing? > > Above there is the output with a few substitutions (XXX and YYY). > http://pastebin.com/nLJ5Zbgj > Nov 24 15:22:03 hostname blkdeactivate[12482]: [UMOUNT]: unmounting vg_yyysap-lv_yyyap_sap (dm-21) mounted on /usr/sap/YYY... done What is blkdeactivate? It does not belong to systemd. > # systemctl --version > systemd 219 > > Thanks for your answer. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Script in /usr/lib/systemd/system-shutdown not executed on init 6
Am Thu, 24 Nov 2016 10:39:52 +0100 schrieb Benoit SCHMID : > Hello, > > On 11/23/2016 03:52 PM, Reindl Harald wrote: > > so why do you strip the whole context and rest of the response? > > > > what is your exactly problem? > > > I think my original question on this thread is clear. > > it should be no rocket science to define a service, order starting > > as needed which ensures at the same time that stop services happens > > in the exactly reverse order > > > It is more than rocket science to have the same behaviour > for my SAP system behaviour on RH7 like on RH6. > On RH6 I could boot my server. > Then a few days after I could manually restart dedicated processes. > On the next shutdown, I knew my processes would be cleanly stopped. > > With RH7, my commands' executions need to be wrapped by systemd > service. Otherwise, as L. Poettering said, these daemons are not > stopped cleanly at shutdown. > This what I have understood. > > > maybe you should stop looking at old sysv scripts and just start > > from scratch and define what you need in a proper systemd unit - > > for many things you will find out that a lot of magic from init > > scripts is not needed at all > > > This is what I am trying to do :-) > > > for me it ssems what you trying to to is wrap everything from a init > > script in a native systemd-unit which is wrong from the start in > > most cases > "trying to wrap everything from init script" is not my overall goal. > My over goal is to administer my SAP systems on my new RH7 servers. > > I have constraints from RH7 and from SAP and from Oracle DB. > After reading that there is systemv systemd generator, > I thought that I could have all the old functionalities with systemd. > It is not the case. > Therefore I am trying to find the best compromises to run my SAP > systems. This implies understanding what I can do and what I cannot > do with systemd. This is why I ask questions like the one on this > thread. What exactly is the init script in question doing, not generalizing it to a simple "echo" and "touch"? I had once an init script that did dirty user switch hackery to first setup some things, then switch the user and start the service by using "su". This does not seem to work properly as "su" spawns a new session. Your service executable is then no longer a real part of what systemd knows about spawning the service. During shutdown, it cannot properly stop it (actually, it simply ignores the PID from the su session) and will eventually simply kill it later. That means, the core of your service looses all stop dependencies defined and will, by definition, killed too late at shutdown. Even OpenRC did not properly stop this service when used in cgroup mode. Using su simply switches to another cgroup as it looked to me and the service wasn't sent signals properly. Instead, you should leave the setup and user switching to systemd. That means setting up directories for example with "RuntimeDirectory", or do some other stuff with "ExecPre". You can switch the user with a native systemd directive, even switching only for "Exec" but not "ExecPre". I my case, I ported the cumbersome script to native systemd mechanics with proper user switching and now everything went well and was solid. The original script was something like a start-stop-daemon emulation, exporting a simple start/stop interface to command line, thus every init system could be easily wrapped around it. Its core daemon is a closed source piece of software and the "init" script was just a convenience compatbility layer to sysvinit systems - but due to its implementation incompatible with cgroup-based init systems. -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=local-fs not enforced
Hello, On 11/24/2016 08:14 PM, Andrei Borzenkov wrote: What is blkdeactivate? It does not belong to systemd. You are asking too much, for me, Andrei because it comes from RH repo :-) I have found this on my host: # cat /usr/lib/systemd/system/blk-availability.service [Unit] Description=Availability of block devices After=lvm2-activation.service lvm2-lvmetad.service iscsi-shutdown.service iscsi.service iscsid.service fcoe.service DefaultDependencies=no Conflicts=shutdown.target [Service] Type=oneshot ExecStart=/usr/bin/true ExecStop=/usr/sbin/blkdeactivate -u -l wholevg -m disablequeueing RemainAfterExit=yes [Install] WantedBy=sysinit.target # systemctl status blk-availability ● blk-availability.service - Availability of block devices Loaded: loaded (/usr/lib/systemd/system/blk-availability.service; disabled; vendor preset: disabled) Active: active (exited) since Thu 2016-11-24 15:25:32 CET; 7h ago Process: 2653 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS) Main PID: 2653 (code=exited, status=0/SUCCESS) CGroup: /system.slice/blk-availability.service Nov 24 15:25:32 beryl5 systemd[1]: Starting Availability of block devices... Nov 24 15:25:32 beryl5 systemd[1]: Started Availability of block devices. Is this enough to answer your question? Thanks for your help. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=user.slice not enforced
Am Wed, 23 Nov 2016 09:14:34 +0100 schrieb Cédric BRINER : > Hi, > > For the context, we are trying to stop a daemon launched by a user... > > >> Hi, > >> > >> sapRunning service contains a "After=user.slice". But at the > >> shutdown, a process (write-sysv-test.pl) running in user.slice is > >> killed before the end of the sapRunning's stop. > > > > Slices are a concept for resource management, and that's what they > > should be used for. Do not user them for anything else, such as > > ordering purposes. > > > > In systemd shutdown ordering is the inverse of start-up ordering, > > and After= and Before= declare the latter. This means that if your > > service has After=user.slice, this means at shutdown your service > > will be stopped first and user.slice second. > Thanks for the clarification. > > But this has not the expected impact. We were wishing with the > "After=user.slice", that the stop sapRunning will occur before any > user commands are stopped. > > Does using "After=user.slice" propagate also on all the *childs*. That > way we could ensure that our stop services' commmand is launched as > the first ever before any kill ? > > The question still remain for us, how can we do to have a daemon > launched by hand, that can be handled by systemd for its stopping. I think you could maybe use targets as synchronizations points... Maybe make a target that starts after multi-user.target and requires it. Then put your service as wanted by this new target (maybe also using after and requires), let's call it sap-started.target. Then make that the default target at boot. That way, on shutdown, it should first stop and wait for sap-started.target, and only then pull down the rest of the system. But what's the purpose of stopping user processes only after this service was stopped? This does make no sense to me. I'd instead define proper dependencies. -- Regards, Kai Replies to list-only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=local-fs not enforced
25.11.2016 00:50, Benoit SCHMID пишет: > Hello, > > > On 11/24/2016 08:14 PM, Andrei Borzenkov wrote: >> What is blkdeactivate? It does not belong to systemd. > > You are asking too much, for me, Andrei because it comes from RH repo :-) > Well, it appears it is part of LVM2. Version 2.02.98 - 15th October 2012 Introduce blkdeactivate script to deactivate block devs with dependencies. > I have found this on my host: > > # cat /usr/lib/systemd/system/blk-availability.service > [Unit] > Description=Availability of block devices > After=lvm2-activation.service lvm2-lvmetad.service > iscsi-shutdown.service iscsi.service iscsid.service fcoe.service > DefaultDependencies=no > Conflicts=shutdown.target > > [Service] > Type=oneshot > ExecStart=/usr/bin/true > ExecStop=/usr/sbin/blkdeactivate -u -l wholevg -m disablequeueing Yes, this is the command that tries to unmount filesystems on LVM2 devices, thus bypassing systemd normal dependencies. The idea of such service is very questionable, but it is probably not something you can really change. You can try to add drop-in to order this service after systemd-logind.service on shutdown, but I would contact RH and verify that they agree to support this. In any case, this is not systemd issue. > RemainAfterExit=yes > > [Install] > WantedBy=sysinit.target > > # systemctl status blk-availability > ● blk-availability.service - Availability of block devices >Loaded: loaded (/usr/lib/systemd/system/blk-availability.service; > disabled; vendor preset: disabled) >Active: active (exited) since Thu 2016-11-24 15:25:32 CET; 7h ago > Process: 2653 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS) > Main PID: 2653 (code=exited, status=0/SUCCESS) >CGroup: /system.slice/blk-availability.service > > Nov 24 15:25:32 beryl5 systemd[1]: Starting Availability of block > devices... > Nov 24 15:25:32 beryl5 systemd[1]: Started Availability of block devices. > > Is this enough to answer your question? > Well, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] after=user.slice not enforced
On Thu, 24 Nov 2016, Kai Krakow wrote: Am Wed, 23 Nov 2016 09:14:34 +0100 schrieb Cédric BRINER : Hi, For the context, we are trying to stop a daemon launched by a user... Hi, sapRunning service contains a "After=user.slice". But at the shutdown, a process (write-sysv-test.pl) running in user.slice is killed before the end of the sapRunning's stop. Slices are a concept for resource management, and that's what they should be used for. Do not user them for anything else, such as ordering purposes. In systemd shutdown ordering is the inverse of start-up ordering, and After= and Before= declare the latter. This means that if your service has After=user.slice, this means at shutdown your service will be stopped first and user.slice second. Thanks for the clarification. But this has not the expected impact. We were wishing with the "After=user.slice", that the stop sapRunning will occur before any user commands are stopped. Does using "After=user.slice" propagate also on all the *childs*. That way we could ensure that our stop services' commmand is launched as the first ever before any kill ? The question still remain for us, how can we do to have a daemon launched by hand, that can be handled by systemd for its stopping. I think you could maybe use targets as synchronizations points... Maybe make a target that starts after multi-user.target and requires it. Then put your service as wanted by this new target (maybe also using after and requires), let's call it sap-started.target. Then make that the default target at boot. That way, on shutdown, it should first stop and wait for sap-started.target, and only then pull down the rest of the system. Simply ordering target units won't help. At boot, systemd does not wait for the first target to be reached before considering starting the units wanted by the second target. Similarly, at shutdown it will not wait for the second group of units to be stopped before stopping the first group of units -- indeed, the target units themselves could be stopped almost immediately. What you can do is have something like this: [Unit] After=multi-user.target [Install] WantedBy=multi-user.target Normally, this unit would be Before=multi-user.target (this is an implicit dependency added when a target Wants= something). By adding an explicit After=multi-user.target dependency, however, you can override this. A unit with this dependency will be "started late" and "stopped early". However, this doesn't really do anything to order it with respect to user sessions. As described elsewhere in this thread, there's no clean way to do that. - Michael___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
