Re: systemd issues

From: Mladen Gogala <>
Date: Wed, 1 May 2019 23:56:18 -0400
Message-ID: <>


I have tested it on OL 7.6 but OL 7.6 still supports sysvinit emulation and the old scripts work fine. I had the service file in /etc/systemd/system and I copied dbstart and dbshut into /usr/local/bin.  I created the environment file /etc/default/oracle. That has worked if there was only a single home. The trick was to create two services, not one. One would fire on startup, the other one on shutdown. However, I was never able to resolve the situation with more than one Oracle home. I finally gave up because sysvinit emulation doesn't seem to be going away anytime soon. It is not removed from the upcoming RH 8:

That should give me another 5 years or so of sysvinit bliss. Hopefully, until then, the people will come to their senses and document the systemd a bit better, so that administrators can write service scripts. The main problem with systemd is that it is developing fast and there is no documentation for it. I am not sure what kind of magic was used to persuade SuSE, Canonical, Red Hat and GNU Foundation to switch to systemd, but it must have been a business decision. If only one of the above has remained faithful to the good, old sysvinit, it would have swept the other ones off the market. I am not a fan of systemd and will not adopt it unless I have to. People are coming to their senses. Brtfs, once touted as the best thing since sliced bread, is fading away into oblivion.


On 5/1/19 4:00 PM, Michael Schmitt wrote:
> Hi Oracle-l
> Has anyone had any luck getting systemd to play nicely with Oracle
> databases?  It seems like every document I have read offers different
> suggestions and each of those come with their own set of issues
> The main issue we are having is systemd killing the oracle processes
> in different circumstances (when databases are manually restarted due
> to cold backups/patching/etc).  We really just want systemd to call
> our custom startup/shutdown scripts when the server reboots (and
> shutdown the database in advance of the network), instead of trying to
> manage the database processes
> Thanks in advance

Mladen Gogala
Database Consultant
Tel: (347) 321-1217

Received on Thu May 02 2019 - 05:56:18 CEST

Original text of this message