mask/unmask is not supported about docker-systemctl-replacement HOT 14 CLOSED

Personally, I don't know what they are doing as I did never have a use for it.

I had a look at this article https://fedoramagazine.org/systemd-masking-units/
and basicially it says that it is about starting dependencies.

However starting dependencies is currently not supported anyway. I have prepared for that while checking for start order but that's about it.

So may be it is sufficient to just do dummy operations for "systemctl mask x" ?

from docker-systemctl-replacement.

Having a dummy would def. be a very good start. E.g. mask == disable, unmask == do nothing
(and that's what I'm trying to hack through for myself - it does not help that my python is at first 10% of the learning curve though)

In case of puppet for elastic they are masking default service and spawning a re-named clone of it. This way whatever you do to original it still stays down while the clones are managed by puppet. Main reason is probably to support many elasticsearch instances on one node.

from docker-systemctl-replacement.

I have implemented the proposal - "mask unit" will effectivly disable the unit, and "unmask unit" will do nothing.

Please test if that is enough for your use case.

from docker-systemctl-replacement.

Hi,
I had a try and it seems either unmask should enable as well or sth else.
Basically following workaround added after the command parsing works with Elasticsearch module:

    if command == 'mask':
        command = 'disable'

    if command == 'unmask':
        command = 'enable'  

While current master fails (didn't have a change to investigate the reason yet)

I had unmask aliased to 'status' before and module failed, when changed to 'enable' module applied successfully

from docker-systemctl-replacement.

I think there was a programming error in there.

Anyway, I changed it to enable/disable. Please try again.

from docker-systemctl-replacement.

Greetings,
I'd need this functionality too (BTW, I'm @IOOOTAlan from issue #32).
The /dev/null linking (mask)/unlinking (unmask) is taken care of by the current commits?

from docker-systemctl-replacement.

I have implemented mask/unmaks according to the systemd standard behaviour which create a symlink to /dev/null

However this results in a nother status of the service file itself which needs more changes in other places of systemctl.py ... notably, the service is "loaded" but "masked" and it is not "enabled" but "masked".

Please check
sudo make real_3102
make test_3102

from docker-systemctl-replacement.

I have implemented the status detection of "masked" for "loaded" and "enabled". On other parts the behaviour is still different to the real systemd's systemctl. However it may already be enough.

v1.3.2312

from docker-systemctl-replacement.

Did you test it?

from docker-systemctl-replacement.

Did you test it?

I don't know if the question is aimed at me, however I did not test it yet: I'm currently on summer holiday/vacation. I'll give it a go as soon as I can, however.
Thanks for implementing this feature so swiftly, though 👍

from docker-systemctl-replacement.

Or perhaps @sergii-sakharov as the original requester? I don't personally have a use for this feature, so it is up to you guys to say the implemention is fine as it is now.

Anyway, I had planned for a release in about two weeks, I'll just push that more to the end of summer then. No pressure needed - have fun! ☺️

from docker-systemctl-replacement.

Any news? I would like to rollup a new release new week.

I don't have any use for it, so if the implementation is lacking then it can take a while to the next official milestone. ;)

from docker-systemctl-replacement.

Hi @gdraheim

I performed some tests on mask/unmask inside an Ubuntu 16.04 container and I think it is working correctly:

• the system-name.service symlink to /dev/null is correctly created in /etc/systemd/system on mask
• that same link is removed on unmask

The only minor issue I found is that the start command on a masked unit is not able to tell that the unit is masked and does not seem able to retrieve the name of the unit:

# systemctl status rsyslog.service
rsyslog.service - System Logging Service
    Loaded: loaded (/lib/systemd/system/rsyslog.service, enabled)
    Active: inactive (dead)
# ls -l /etc/systemd/system/
total 16
drwxr-xr-x 2 root root 4096 Aug  8 02:03 getty.target.wants
drwxr-xr-x 1 root root 4096 Sep  1 07:44 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Aug  8 02:03 sysinit.target.wants
lrwxrwxrwx 1 root root   35 Sep  1 07:44 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Aug  8 02:04 timers.target.wants
# systemctl mask rsyslog
# systemctl status rsyslog.service
rsyslog.service - 
    Loaded: masked (None, masked)
    Active: inactive (dead)
# ls -l /etc/systemd/system/
total 16
drwxr-xr-x 2 root root 4096 Aug  8 02:03 getty.target.wants
drwxr-xr-x 1 root root 4096 Sep  1 07:44 multi-user.target.wants
lrwxrwxrwx 1 root root    9 Sep  1 07:45 rsyslog.service -> /dev/null
drwxr-xr-x 2 root root 4096 Aug  8 02:03 sysinit.target.wants
lrwxrwxrwx 1 root root   35 Sep  1 07:44 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Aug  8 02:04 timers.target.wants
# systemctl start rsyslog.service
ERROR:systemctl:Unit  could not be found.
# systemctl unmask rsyslog.service
# ls -l /etc/systemd/system/
total 16
drwxr-xr-x 2 root root 4096 Aug  8 02:03 getty.target.wants
drwxr-xr-x 1 root root 4096 Sep  1 07:44 multi-user.target.wants
drwxr-xr-x 2 root root 4096 Aug  8 02:03 sysinit.target.wants
lrwxrwxrwx 1 root root   35 Sep  1 07:44 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Aug  8 02:04 timers.target.wants
# systemctl status rsyslog.service
rsyslog.service - System Logging Service
    Loaded: loaded (/lib/systemd/system/rsyslog.service, enabled)
    Active: inactive (dead)
# systemctl start rsyslog.service
# systemctl status rsyslog.service
rsyslog.service - System Logging Service
    Loaded: loaded (/lib/systemd/system/rsyslog.service, enabled)
    Active: active (running)

Apart from this, I guess it works 👍
Thank you very much!

from docker-systemctl-replacement.

I have added your scenario as "make test_8034".

Actually, I have concluded that it needed two enhancements - for one part, a masked unit did not have a UnitConf.name() but it should actually.

And for the other part, it does not make sense to handover a masked unit to start_unit(x) anyway, so that start_units(xx) filters them out when computing the starting order (from the After= clauses in the confs).

As a result, the "start [masked]" does not do anything now, not even an error message like "not found".

from docker-systemctl-replacement.