Bug 44274 - No warning message if UCR variable <service>/autostart=false
No warning message if UCR variable <service>/autostart=false
Status: NEW
Product: UCS
Classification: Unclassified
Component: General
UCS 4.2
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-04-04 00:41 CEST by Alexander Kläser
Modified: 2017-04-04 18:22 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 5: Will affect all installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.229
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional): Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kläser univentionstaff 2017-04-04 00:41:27 CEST
It took me some time to realize that I could not stop (or start) a service as the corresponding UCR variable was set to <service>/autostart=false. In the lib file /usr/share/univention-config-registry/init-autostart.lib, there is a warning forseen, however, it seems that the script never comes to this point as it exists earlier. We really need to show a warning message if a service is completely disabled.
Comment 1 Philipp Hahn univentionstaff 2017-04-04 17:20:19 CEST
# systemctl status cron.service
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled)
   Active: active (running) since Di 2017-04-04 17:00:36 CEST; 13min ago
     Docs: man:cron(8)
 Main PID: 750 (cron)
   CGroup: /system.slice/cron.service
           └─750 /usr/sbin/cron -f
...
# ucr set cron/autostart=no
Setting cron/autostart
File: /etc/cron.d/univention-ucr-cronjobs
Module: autostart

# service cron stop
# service cron status
● cron.service
   Loaded: masked (/dev/null)
   Active: inactive (dead)

# service cron start
Failed to start cron.service: Unit cron.service is masked.

# systemctl start cron.service
Failed to start cron.service: Unit cron.service is masked

BUT

# invoke-rc.d start cron
-
# /etc/init.d/cron start
-

# sed -ne '/masked/,/masked/p' /lib/lsb/init-functions.d/40-systemd
    # Don't try to run masked services. Don't check for errors, if
    # this errors, we'll just call systemctl and possibly explode
    # there.
    state=$(systemctl -p LoadState show $service 2>/dev/null)
    [ "$state" = "LoadState=masked" ] && return 0
Comment 2 Alexander Kläser univentionstaff 2017-04-04 18:21:21 CEST
Hm...

> $ ucr set umc/server/autostart=no
> Setting umc/server/autostart
> Module: autostart
> $ systemctl stop univention-management-console-server.service 
> Warning: Unit file of univention-management-console-server.service changed on disk, 'systemctl daemon-reload' recommended.
> $ ucr set umc/server/autostart=yes
> Setting umc/server/autostart
> Module: autostart
> $ systemctl stop univention-management-console-server.service 
> Warning: Unit file of univention-management-console-server.service changed on disk, 'systemctl daemon-reload' recommended.
> $ ps afx | grep manage
>  2762 pts/0    S+     0:00          \_ grep --color=auto manage
>  2494 ?        Sl     0:00 /usr/bin/python2.7 /usr/sbin/univention-management-console-web-server start
> $ systemctl start univention-management-console-server.service 
> Warning: Unit file of univention-management-console-server.service changed on disk, 'systemctl daemon-reload' recommended.
> $ ps afx | grep manage
>  2800 pts/0    S+     0:00          \_ grep --color=auto manage
>  2494 ?        Sl     0:00 /usr/bin/python2.7 /usr/sbin/univention-management-console-web-server start
>  2783 ?        S      0:00 /usr/bin/python2.7 /usr/sbin/univention-management-console-server start
Comment 3 Alexander Kläser univentionstaff 2017-04-04 18:22:38 CEST
... but I have the same behaviour with cron.