[systemd-devel] Masking socket activated services is broken

[Michael Biebl]

[stupid gmail which dropped the systemd-devel mailing list, so quoting
it full here]

2013/6/19 Kok, Auke-jan H <auke-jan.h.kok at intel.com>:
> On Wed, Jun 19, 2013 at 9:47 AM, Michael Biebl <mbiebl at gmail.com> wrote:
>> 2013/6/19 Kok, Auke-jan H <auke-jan.h.kok at intel.com>:
>>> On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl <mbiebl at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I've run "systemctl mask rsyslog.service", but the service can still
>>>> be started via
>>>> "systemctl start rsyslog.service" or by generating a log message.
>>>>
>>>> Looks like a bug to me.
>>>
>>> Why would it be? Masking just removes the unit from the dependency
>>> tree of a target - I kinda prefer being able to mask and manually
>>> start a unit. The alternative, which is what you suggest, is that the
>>
>> Hm, are you maybe confusing disable with mask here?
>> disable usually removes the unit from the various target.wants.
>>
>> And here I agree with you completely: One should still be able to
>> start a  disabled service manually.
>
> you're right - I was indeed confused with disable... I can see how
> masking a service that is socket activated shouldn't ever restart
> it... seems as if something is completely ignoring the symlink.
>
> I still think that the root user should be able to start stuff that
> has been "disabled" but in this case it probably doesn't make any
> sense.

mask is the big hammer, a service which is masked should not be
started, no matter how the start request is triggered: manually, via
targets or (socket/D-Bus) activation

To illustrate the problem: (non socket-activated service)

root at pluto:~# systemctl start cron.service
root at pluto:~# systemctl status cron.service
cron.service - Command Scheduler
   Loaded: loaded (/lib/systemd/system/cron.service; enabled)
   Active: active (running) since Mi 2013-06-19 19:28:42 CEST; 3s ago
 Main PID: 26041 (cron)
   CGroup: name=systemd:/system/cron.service
           └─26041 /usr/sbin/cron -f

Jun 19 19:28:42 pluto systemd[1]: Started Command Scheduler.
Jun 19 19:28:43 pluto /usr/sbin/cron[26041]: (CRON) INFO (pidfile fd = 3)
Jun 19 19:28:43 pluto /usr/sbin/cron[26041]: (CRON) INFO (Skipping
@reboot jobs -- not system startup)

root at pluto:~# systemctl stop cron.service

root at pluto:~# systemctl mask cron.service
ln -s '/dev/null' '/etc/systemd/system/cron.service'

root at pluto:~# systemctl start cron.service
Failed to issue method call: Unit cron.service is masked.


In contrast to a socket-activated service (rsyslog)

root at pluto:~# systemctl status rsyslog.service
rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled)
   Active: active (running) since Mi 2013-06-19 17:34:39 CEST; 1h 54min ago
 Main PID: 644 (rsyslogd)
   CGroup: name=systemd:/system/rsyslog.service
           └─644 /usr/sbin/rsyslogd -n

Jun 19 17:34:39 pluto systemd[1]: Started System Logging Service.

root at pluto:~# systemctl stop syslog.socket rsyslog.service

root at pluto:~# systemctl mask rsyslog.service
ln -s '/dev/null' '/etc/systemd/system/rsyslog.service'

root at pluto:~# systemctl start rsyslog.service

root at pluto:~# systemctl status rsyslog.service
rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; masked)
   Active: active (running) since Mi 2013-06-19 19:30:07 CEST; 4s ago
 Main PID: 26099 (rsyslogd)
   CGroup: name=systemd:/system/rsyslog.service
           └─26099 /usr/sbin/rsyslogd -n

Jun 19 19:30:07 pluto systemd[1]: Starting System Logging Service...
Jun 19 19:30:07 pluto systemd[1]: Started System Logging Service.


See the inconsistency?
In case of rsyslog, I can also trigger the start, by starting
syslog.socket again and running logger.


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?