Bug 8723

Created attachment 3392 [details]
oracle-xe initscript

This was happening some months ago, and then mysteriously worked.

Hmm, that script is pretty convoluted. It even asks for user input at times :s

It would be good if someone sat down and wrote a proper systemd unit for it and pushed it usptream to avoid all these things that could cause problems.

If you put a set -x somewhere in the script and everything should be logged into the journal (I think - not tried this!) which may show you exactly where it's failing.

One thing that may not work too well is the use of "su" in the script which might cause some problems with cgroups for tracking processes and such like. Better to split things up to individual units that can run and use the built in systemd User= directive in the unit.

(In reply to comment #2)
> Hmm, that script is pretty convoluted. It even asks for user input at times :s

Most of the script is actually part of the install, and only gets run once to configure the listener server.

> 
> It would be good if someone sat down and wrote a proper systemd unit for it and
> pushed it usptream to avoid all these things that could cause problems.
> 
> If you put a set -x somewhere in the script and everything should be logged
> into the journal (I think - not tried this!) which may show you exactly where
> it's failing.
> 
> One thing that may not work too well is the use of "su" in the script which
> might cause some problems with cgroups for tracking processes and such like.
> Better to split things up to individual units that can run and use the built in
> systemd User= directive in the unit.

I'll try the -x approach, but oracle-xe isn't open source, so I don't know if Oracle takes code submissions.  Once we know what's happening, I'll see if they have a bug tracker open to the public.

Is this still valid?

CC: (none) => nic

It's maybe still valid but as it's not open source we cannot fix it really.

Systemd might behave better with it's sysvinit generator these days but I'm not overly convinced that would be the case.

Seems Arch ship a kind of wrapper package that includes a simple systemd unit so I'm sure those willing to make it work could extract the systemd unit from the tarball there and place it in /etc/systemd/system/

It's also important to ensure that it's been configured before trying to start it on boot otherwise it may fail (and may take a while to timeout slowing down boot).

https://aur.archlinux.org/packages/oracle-xe/?comments=all

Will resolve as wontfix as there is not overly much we can do. As "Oracle Linux" is basically a rsync of RHEL, we should expect to see native upstream systemd support (of no doubt questionable quality) at some point.

Status: NEW => RESOLVED
Resolution: (none) => WONTFIX

FWIW, it works just fine with $SYSTEMCTL_SKIP_REDIRECT.  systemd should really have an option to set this without having to start stuff by hand.

(In reply to Frank Griffin from comment #6)
> FWIW, it works just fine with $SYSTEMCTL_SKIP_REDIRECT.  systemd should
> really have an option to set this without having to start stuff by hand.

That doesn't really make any sense. This is just a hacky workaround for wrapper scripts (e.g. /usr/sbin/service) for running stuff manually - i.e. bypassing systemd completely and running stuff in the same context as your shell (i.e. a messy environment).

This can never work at startup and isn't really a "solution", it's just a hack.

I agree it's a hack, but as long as major packages (Oracle, JBoss) seem to require a "messy" environment, systemd ought to offer it as an option, e. g.

    systemctl noredirect oracle-xe

(In reply to Frank Griffin from comment #8)
> I agree it's a hack, but as long as major packages (Oracle, JBoss) seem to
> require a "messy" environment, systemd ought to offer it as an option, e. g.
> 
>     systemctl noredirect oracle-xe

Again, this doesn't make sense. The SKIP_REDIRECT env var is to skip redirecting from "service" to "systemctl", there is no equivalent the other way around at all as systemctl *never* redirects in the first place. It's a one way option and doing it the other way around doesn't make any sense (it's also something that's basically impossible - systemctl is basically a tool to ask pid1 do do something. The problem you're encountering is that this script is so messy and does such weird shit that pid1 doesn't like starting it. What you're really asking is for systemctl to just shell out to some hacky bunch of cruft rather than talk via defined APIs to a service manager daemon. I'm afraid that is *never* going to fly!! There is a correct solution - fix the broken services (and this can almost certainly be done *without* having to modify code - just provide sane systemd units) - but this most certainly is not it!