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
Am 18.12.2017 um 19:40 schrieb 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

this overrides also LSB init scripts with the same name with a symlink
to /dev/null

> 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 <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
2017-12-19 2:58 GMT+01:00 Reindl Harald <***@thelounge.net>:

>
>
> Am 19.12.2017 um 02:23 schrieb Cecil Westerhof:
>
>> 2017-12-19 1:36 GMT+01:00 Reindl Harald <***@thelounge.net <mailto:
>> ***@thelounge.net>>:
>>
>>
>>
>> Am 18.12.2017 um 19:40 schrieb 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
On Mo, 18.12.17 19:40, Cecil Westerhof (***@gmail.com) wrote:

> 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

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
Am 19.12.2017 um 20:05 schrieb Lennart Poettering:
> On Mo, 18.12.17 19:40, Cecil Westerhof (***@gmail.com) wrote:
>
>> 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
>
> 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
On Di, 19.12.17 20:34, Reindl Harald (***@thelounge.net) wrote:

>
>
> Am 19.12.2017 um 20:05 schrieb Lennart Poettering:
> > On Mo, 18.12.17 19:40, Cecil Westerhof (***@gmail.com) wrote:
> >
> > > 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
> >
> > 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
On Tue, Dec 19, 2017 at 2:34 PM, Reindl Harald <***@thelounge.net> wrote:
> Am 19.12.2017 um 20:05 schrieb Lennart Poettering:
>> On Mo, 18.12.17 19:40, Cecil Westerhof (***@gmail.com) wrote:


>>> 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
>>
>> 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
Am 20.12.2017 um 14:52 schrieb Tom H:
> On Tue, Dec 19, 2017 at 2:34 PM, Reindl Harald <***@thelounge.net> wrote:
>> Am 19.12.2017 um 20:05 schrieb Lennart Poettering:
>>> On Mo, 18.12.17 19:40, Cecil Westerhof (***@gmail.com) wrote:
>
>
>>>> 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
>>>
>>> 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
On Wed, Dec 20, 2017 at 8:59 AM, Reindl Harald <***@thelounge.net> wrote:
> Am 20.12.2017 um 14:52 schrieb Tom H:
>> On Tue, Dec 19, 2017 at 2:34 PM, Reindl Harald <***@thelounge.net>
>> wrote:


>>> 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.


> 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.


> 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
Am 23.12.2017 um 18:28 schrieb Tom H:
>> 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
<J.deBoynePollard-***@ntlworld.com> wrote:
> 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
Am 23.12.2017 um 18:31 schrieb Tom H:
> On Wed, Dec 20, 2017 at 5:39 PM, Jonathan de Boyne Pollard
> <J.deBoynePollard-***@ntlworld.com> wrote:
>> 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.

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...