Discussion:
Disabling tomcat8
(too old to reply)
Cecil Westerhof
2017-12-18 18:40:47 UTC
Permalink
Raw Message
There is a system with tomcat8 installed and enabled. At the moment it is
not used, so I thought it better to disable it.

When I enter:
systemctl disable tomcat8.service

I get:
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8

Other services I can enable and disable. I can stop (and start) tomcat 8,
but then I always have to stop tomcat8 after a reboot.

What could be the problem?

Status information:
● tomcat8.service - LSB: Start Tomcat.
Loaded: loaded (/etc/init.d/tomcat8; generated; vendor preset:
enabled)
Active: inactive (dead)
Docs: man:systemd-sysv-generator(8)

Dec 17 11:54:57 munus.decebal.nl systemd[1]: Starting LSB: Start
Tomcat....
Dec 17 11:55:03 munus.decebal.nl tomcat8[1399]: Starting Tomcat servlet
engine: tomcat8.
Dec 17 11:55:03 munus.decebal.nl systemd[1]: Started LSB: Start Tomcat..
Dec 17 15:05:23 munus.decebal.nl systemd[1]: Stopping LSB: Start
Tomcat....
Dec 17 15:05:23 munus.decebal.nl tomcat8[14181]: Stopping Tomcat
servlet engine: tomcat8.
Dec 17 15:05:23 munus.decebal.nl systemd[1]: Stopped LSB: Start Tomcat..
--
Cecil Westerhof
Reindl Harald
2017-12-19 00:36:38 UTC
Permalink
Raw Message
    tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
    Executing: /lib/systemd/systemd-sysv-install disable tomcat8
Other services I can enable and disable. I can stop (and start) tomcat
8, but then I always have to stop tomcat8 after a reboot.
What could be the problem?
your distribution / package

as you can see it's not a systemd unit at all
/etc/init.d/tomcat8

use "systemctl mask" instead "sytecmtl disable" if you *really* want to
disable stuff and ensue it never ever can be enabled again

this overrides also LSB init scripts with the same name with a symlink
to /dev/null
    ● tomcat8.service - LSB: Start Tomcat.
enabled)
       Active: inactive (dead)
         Docs: man:systemd-sysv-generator(8)
    Dec 17 11:54:57 munus.decebal.nl <http://munus.decebal.nl>
systemd[1]: Starting LSB: Start Tomcat....
    Dec 17 11:55:03 munus.decebal.nl <http://munus.decebal.nl>
tomcat8[1399]: Starting Tomcat servlet engine: tomcat8.
    Dec 17 11:55:03 munus.decebal.nl <http://munus.decebal.nl>
systemd[1]: Started LSB: Start Tomcat..
    Dec 17 15:05:23 munus.decebal.nl <http://munus.decebal.nl>
systemd[1]: Stopping LSB: Start Tomcat....
    Dec 17 15:05:23 munus.decebal.nl <http://munus.decebal.nl>
tomcat8[14181]: Stopping Tomcat servlet engine: tomcat8.
    Dec 17 15:05:23 munus.decebal.nl <http://munus.decebal.nl>
systemd[1]: Stopped LSB: Start Tomcat..
Cecil Westerhof
2017-12-19 09:28:12 UTC
Permalink
Raw Message
Post by Cecil Westerhof
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8
Other services I can enable and disable. I can stop (and start)
tomcat 8, but then I always have to stop tomcat8 after a reboot.
What could be the problem?
your distribution / package
as you can see it's not a systemd unit at all
/etc/init.d/tomcat8
use "systemctl mask" instead "sytecmtl disable" if you *really* want
to disable stuff and ensue it never ever can be enabled again
​That works. Not important at the moment, but is there a way to install
it correctly?​
just don't use legacy sysv-init scripts, no idea how much old cruft magic
the tomcat ones contains which may be hard to port or not
​
​I found and used (with a few modifications):
http://unquietwiki.blogspot.nl/2015/05/the-simplest-way-
to-get-tomcat-as.html

That did not work.

I now found:
https://technet.sector19.net/linux/create-systemd-service-for-tomcat/

When I have a bit more time I am going to try that one.​
​
--
Cecil Westerhof
Lennart Poettering
2017-12-19 19:05:53 UTC
Permalink
Raw Message
Post by Cecil Westerhof
There is a system with tomcat8 installed and enabled. At the moment it is
not used, so I thought it better to disable it.
systemctl disable tomcat8.service
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8
This means the service in question is not a native systemd service,
but a legacy SysV service, that is only hooked in with distro-specific
shell glue. If that doesn't work it's not an upstream issue, you need
to contact your downstream distribution for help, as they put together
the shell script glue.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2017-12-19 19:34:03 UTC
Permalink
Raw Message
Post by Lennart Poettering
Post by Cecil Westerhof
There is a system with tomcat8 installed and enabled. At the moment it is
not used, so I thought it better to disable it.
systemctl disable tomcat8.service
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8
This means the service in question is not a native systemd service,
but a legacy SysV service, that is only hooked in with distro-specific
shell glue. If that doesn't work it's not an upstream issue, you need
to contact your downstream distribution for help, as they put together
the shell script glue
in 2017 it shpuld be a native systemd-unit but from where comes the
"vendor preset: enabled" in case of a generated unit?

Loaded: loaded (/etc/init.d/tomcat8; generated; vendor preset: enabled)
Lennart Poettering
2017-12-20 10:53:43 UTC
Permalink
Raw Message
Post by Lennart Poettering
Post by Cecil Westerhof
There is a system with tomcat8 installed and enabled. At the moment it is
not used, so I thought it better to disable it.
systemctl disable tomcat8.service
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8
This means the service in question is not a native systemd service,
but a legacy SysV service, that is only hooked in with distro-specific
shell glue. If that doesn't work it's not an upstream issue, you need
to contact your downstream distribution for help, as they put together
the shell script glue
in 2017 it shpuld be a native systemd-unit but from where comes the "vendor
preset: enabled" in case of a generated unit?
Loaded: loaded (/etc/init.d/tomcat8; generated; vendor preset: enabled)
Hmm, we might indeed want to hide the preset data when something's a
generated unit.

Lennart
--
Lennart Poettering, Red Hat
Tom H
2017-12-20 13:52:12 UTC
Permalink
Raw Message
Post by Lennart Poettering
Post by Cecil Westerhof
There is a system with tomcat8 installed and enabled. At the moment it is
not used, so I thought it better to disable it.
systemctl disable tomcat8.service
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8
This means the service in question is not a native systemd service,
but a legacy SysV service, that is only hooked in with distro-specific
shell glue. If that doesn't work it's not an upstream issue, you need
to contact your downstream distribution for help, as they put together
the shell script glue
in 2017 it shpuld be a native systemd-unit but from where comes the "vendor
preset: enabled" in case of a generated unit?
The usual reason for not having a native unit is that you can't force
developers to do that work. Also, some sysvrc scripts are so
convoluted that the developers prefer to let the generator take care
of business.
Loaded: loaded (/etc/init.d/tomcat8; generated; vendor preset: enabled)
It's standard for generated units:

***@1604 ~ # systemctl status apparmor.service
● apparmor.service - LSB: AppArmor initialization
Loaded: loaded (/etc/init.d/apparmor; bad; vendor preset: enabled)
Active: active (exited) since Wed 2017-12-20 08:27:53 EST; 10min ago
Docs: man:systemd-sysv-generator(8)
Process: 274 ExecStart=/etc/init.d/apparmor start (code=exited,
status=0/SUCCESS)

Dec 20 08:07:02 1604 systemd[1]: Starting LSB: AppArmor initialization...
Dec 20 08:07:03 1604 apparmor[274]: * Starting AppArmor profiles
Dec 20 08:27:53 1604 apparmor[274]: ...done.
Dec 20 08:27:53 1604 systemd[1]: Started LSB: AppArmor initialization.
***@1604 ~ #
Reindl Harald
2017-12-20 13:59:32 UTC
Permalink
Raw Message
Post by Tom H
Post by Lennart Poettering
Post by Cecil Westerhof
There is a system with tomcat8 installed and enabled. At the moment it is
not used, so I thought it better to disable it.
systemctl disable tomcat8.service
tomcat8.service is not a native service, redirecting to
systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable tomcat8
This means the service in question is not a native systemd service,
but a legacy SysV service, that is only hooked in with distro-specific
shell glue. If that doesn't work it's not an upstream issue, you need
to contact your downstream distribution for help, as they put together
the shell script glue
in 2017 it shpuld be a native systemd-unit but from where comes the "vendor
preset: enabled" in case of a generated unit?
The usual reason for not having a native unit is that you can't force
developers to do that work. Also, some sysvrc scripts are so
convoluted that the developers prefer to let the generator take care
of business
in doubt where is the problem to point ExecStart/Stop to the elsewehere
located sysv-initscript even without change that?

the benefit is that you still have the
/etc/systemd/system/servicename.service.d snippets and can use namespace
options like ReadOnlyDirectory and so on as well as
override/disable/enable works proper for around 10 minutes of work

guess what Fedora did with "iptables.service"

so no, i don't see an excuse after that many years for crap within
/etc/init.d/

[***@srv-rhsoft:~]$ cat /usr/libexec/iptables/iptables.init start
#!/bin/bash
#
# iptables Start iptables firewall
#
# chkconfig: 2345 08 92
# description: Starts, stops and saves iptables firewall
#
# config: /etc/sysconfig/iptables
# config: /etc/sysconfig/iptables-config
#
### BEGIN INIT INFO
# Provides: iptables
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop iptables firewall
# Description: Start, stop and save iptables firewall
### END INIT INFO
[***@srv-rhsoft:~]$ cat /usr/lib/systemd/system/iptables.service
[Unit]
Description=IPv4 firewall with iptables
After=syslog.target
AssertPathExists=/etc/sysconfig/iptables

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/libexec/iptables/iptables.init start
ExecReload=/usr/libexec/iptables/iptables.init reload
ExecStop=/usr/libexec/iptables/iptables.init stop
Environment=BOOTUP=serial
Environment=CONSOLETYPE=serial
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=basic.target
[***@srv-rhsoft:~]$
Tom H
2017-12-23 17:28:25 UTC
Permalink
Raw Message
Post by Reindl Harald
Post by Tom H
Post by Reindl Harald
in 2017 it shpuld be a native systemd-unit but from where comes the
"vendor preset: enabled" in case of a generated unit?
The usual reason for not having a native unit is that you can't force
developers to do that work. Also, some sysvrc scripts are so
convoluted that the developers prefer to let the generator take care
of business
in doubt where is the problem to point ExecStart/Stop to the
elsewehere located sysv-initscript even without change that?
That's what the sysv generator does. If you're going to write a unit,
you may as well write a "proper" one.
Post by Reindl Harald
the benefit is that you still have the
/etc/systemd/system/servicename.service.d snippets and can use namespace
options like ReadOnlyDirectory and so on as well as override/disable/enable
works proper for around 10 minutes of work
guess what Fedora did with "iptables.service"
I'd guess that it was more about keeping non-standard verbs, like
"save", than anything else.
Post by Reindl Harald
so no, i don't see an excuse after that many years for crap within
/etc/init.d/
I doubt that distributions using a generator for sysvrc scripts agree
with you - or they've have systemd units for everything.
Reindl Harald
2017-12-23 17:32:21 UTC
Permalink
Raw Message
Post by Tom H
Post by Reindl Harald
so no, i don't see an excuse after that many years for crap within
/etc/init.d/
I doubt that distributions using a generator for sysvrc scripts agree
with you - or they've have systemd units for everything
i don't give a damn about random distributions agree or not

* i was there as systemd was introduced in Fedora
* the shape of the distribution was a bad joke
* i spent days and nights to override the init.d crap
* https://fedoraproject.org/wiki/Features/systemd

that is *seven years* ago - there is no single excuse in 2017
Jonathan de Boyne Pollard
2017-12-20 22:39:27 UTC
Permalink
Raw Message
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Tom H
2017-12-23 17:31:12 UTC
Permalink
Raw Message
On Wed, Dec 20, 2017 at 5:39 PM, Jonathan de Boyne Pollard
Post by Tom H
The usual reason for not having a native unit is that you can't force
developers to do that work.
Psst! This discussion is predicated upon a falsehood. There is an
abundance of service units for Tomcat, and has been for years. They
are part of the systemd House of Horror. Sad to say: M. Westerhof has
already found two of those.
Feel free to email debian-devel@ that maintainers ought to include
systemd units in all of their packages by grabbing ready-made units
elsewhere. Good luck.

This isn't how it worls.
Reindl Harald
2017-12-23 17:35:17 UTC
Permalink
Raw Message
Post by Tom H
On Wed, Dec 20, 2017 at 5:39 PM, Jonathan de Boyne Pollard
Post by Tom H
The usual reason for not having a native unit is that you can't force
developers to do that work.
Psst! This discussion is predicated upon a falsehood. There is an
abundance of service units for Tomcat, and has been for years. They
are part of the systemd House of Horror. Sad to say: M. Westerhof has
already found two of those.
systemd units in all of their packages by grabbing ready-made units
elsewhere. Good luck.
This isn't how it worls.
and why don't do that damned maintainers their job?

seriously i have enough of half baken migrations to whatever after that
many years in the IT where everytime people creep out of their holes
"it's for freed, you can't demand anything because it's free"

so don't move to anything if you don't do it proper

"it's free" is no valid excuse for shitty work

Jonathan de Boyne Pollard
2017-12-20 22:38:38 UTC
Permalink
Raw Message
_______________________________________________
systemd-devel mailing list
systemd-***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Loading...