[stupid gmail which dropped the systemd-devel mailing list, so quoting
it full here]
2013/6/19 Kok, Auke-jan H <auke-jan.h....@intel.com>:
> On Wed, Jun 19, 2013 at 9:47 AM, Michael Biebl <mbi...@gmail.com> wrote:
>> 2013/6/19 Kok, Auke-jan H <auke-jan.h....@intel.com>:
>>> On Tue, Jun 18, 2013 at 10:15 PM, Michael Biebl <mbi...@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@pluto:~# systemctl start cron.service
root@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@pluto:~# systemctl stop cron.service
root@pluto:~# systemctl mask cron.service
ln -s '/dev/null' '/etc/systemd/system/cron.service'
root@pluto:~# systemctl start cron.service
Failed to issue method call: Unit cron.service is masked.
In contrast to a socket-activated service (rsyslog)
root@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@pluto:~# systemctl stop syslog.socket rsyslog.service
root@pluto:~# systemctl mask rsyslog.service
ln -s '/dev/null' '/etc/systemd/system/rsyslog.service'
root@pluto:~# systemctl start rsyslog.service
root@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?
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
