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
23.11.2016 11:08, Benoit SCHMID пишет:
> Hello,
>
> On 11/22/2016 11:46 AM, Holger Kiehl wrote:
>> But users do test things under their login environment and expect them
>> to run in this environment. So for some applications this is a must.
> I fully agree with you.
>
> I am a SAP admin.
>
>
Hello,
On 11/22/2016 11:46 AM, Holger Kiehl wrote:
> But users do test things under their login environment and expect them
> to run in this environment. So for some applications this is a must.
I fully agree with you.
I am a SAP admin.
As far as SAP is concerned, to manage the service, the
Hello,
On 11/22/2016 10:58 AM, Jonathan de Boyne Pollard wrote:
>
> It's now 2016, and the first rule for migrating to systemd applies
> even to Oracle softwares.
>
> * http://jdebp.eu./FGA/systemd-house-of-horror/daemonize.html#first-rule
>
> *
On Tue, 22.11.16 09:39, Benoit SCHMID (benoit.sch...@unige.ch) wrote:
> Good morning,
>
> This topic is related to the systemd-sysv-generator thread submited by
> my colleague.
> I post it with another subject becaus I prefer to create another thread
> as it would make too many different
Hello,
I have tried with
"User=oracle","Environment=ORACLE_HOME=/oracle/XXX/12102" and removing
the "su -".
You are right.
Now I have:
# systemctl status ora_lsnr_XXX.service
● ora_lsnr_XXX.service - Oracle Listener XXX
Loaded: loaded (/etc/systemd/system/ora_lsnr_XXX.service; disabled;
On Tue, 22 Nov 2016, Mantas Mikulėnas wrote:
> So, uh, that sounded like you value updating one file less (and even mixing
> user and daemon configs) above having the service actually work?
>
But users do test things under their login environment and expect them
to run in this environment. So for
So, uh, that sounded like you value updating one file less (and even mixing
user and daemon configs) above having the service actually work?
Not that it's an excuse anyway. Systemd units have EnvironmentFile= for
importing environment variables. Even init.d scripts can use `source` with
the same
Benoit SCHMID:
echo -n "Starting Oracle Listener: "
su - $ORA_OWNR -c "env ORACLE_HOME=/oracle/XXX/12102
/oracle/XXX/12102/bin/lsnrctl start LISTENER_XXX"
Don't abuse su for dropping privileges.
* http://jdebp.eu./FGA/dont-abuse-su-for-dropping-privileges.html
It's now
Hello,
On 11/22/2016 10:58 AM, Jonathan de Boyne Pollard wrote:
> Don't abuse su for dropping privileges.
I agree that using su has drawbacks.
But it also have advantages.
When you upgrade your db, you upgrade the environment variables.
Therefore using su allow you to centralised everything in
On Tue, Nov 22, 2016 at 11:39 AM, Benoit SCHMID wrote:
...
> 2. This service starts /etc/rc.d/init.d/sap start.
> % cat /etc/rc.d/init.d/sap
> #!/bin/bash
> ...
> case "$1" in
> start)
> # Oracle listener and instance startup
> echo -n "Starting Oracle
Good morning,
This topic is related to the systemd-sysv-generator thread submited by
my colleague.
I post it with another subject becaus I prefer to create another thread
as it would make too many different questions in the same thread.
1. I have defined a service.
It is started by systemd on
12 matches
Mail list logo