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"?