On 11/3/19 1:04 PM, John M. Harris Jr wrote:
By the way, both
cockpit.service and cockpit.socket were enabled by default.
That's odd.... While I've manually disabled the socket
[root@f31sd ~]# systemctl status cockpit.service
● cockpit.service - Cockpit Web Service
Loaded: loaded (/usr/lib/systemd/system/cockpit.service; static; vendor preset:
disabled)
Active: inactive (dead)
Docs: man:cockpit-ws(8)
Vendor preset for the service is "disabled"
[root@f31sd ~]# systemctl status cockpit.socket
● cockpit.socket - Cockpit Web Service Socket
Loaded: loaded (/usr/lib/systemd/system/cockpit.socket; disabled; vendor preset:
enabled)
Active: inactive (dead)
Docs: man:cockpit-ws(8)
Listen: [::]:9090 (Stream)
Vendor preset for the socket is "enabled" and I've disabled it on this
system
[root@f31sd ~]# systemctl enable cockpit.service
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
Is what happens when one tries to enable cockpit.service since it is a static service.
Are you saying yours shows "enabled"?
--
The key to getting good answers is to ask good questions.