nexedi / slapos.package

@rafael , @alain.takoudjou , @kirr : could you review this commit please ?

After running these tasks, systemctl status cron.service displays :

    Tasks: 5870

instead of :

    Tasks: 5870 (limit: 6297)

which makes me believe the goal has been reached

Edited : s/supervisorctl/systemctl, copy-paste issue

@Nicolas, thanks for dealing with this issue.

I don't know systemd and cgroups, but I quickly checked and it turns out it is possible to adjust systemd configuration & actual cgroups settings without restarting the service via systemctl daemon-reload:

before:

root@deco:/home/kirr# systemctl status cron
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-01-25 11:27:20 MSK; 57min ago
     Docs: man:cron(8)
 Main PID: 620 (cron)
    Tasks: 1 (limit: 4915)
   Memory: 12.7M
   CGroup: /system.slice/cron.service
           └─620 /usr/sbin/cron -f

Note the limit and pid(cron) = 620.

Now let's adjust:

root@deco:/home/kirr# mkdir -p /etc/systemd/system/cron.service.d/
root@deco:/home/kirr# cat >/etc/systemd/system/cron.service.d/override.conf
[Service]
TasksMax=infinity

root@deco:/home/kirr# systemctl daemon-reload

root@deco:/home/kirr# systemctl status cron
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/cron.service.d
           └─override.conf
   Active: active (running) since Fri 2019-01-25 11:27:20 MSK; 59min ago
     Docs: man:cron(8)
 Main PID: 620 (cron)
    Tasks: 1
   Memory: 12.7M
   CGroup: /system.slice/cron.service
           └─620 /usr/sbin/cron -f

Note that the limit is gone, but pid(cron) remained 620 - this means that the cron process was not restarted.

Systemctl man discusses the difference in between reload (make the actual service to reload/reapply its configuration) and daemon-reload (make systemd to reload systemd configuration only and reapply it). Please refer to the documentation for details.

I would also suggest to put a comment into added /etc/systemd/system/cron.service.d/override.conf why we override the limit.

Hope this helps a bit and thanks again for dealing with the problem,
Kirill

( one can also inspect/modify actual cgroup state, not what systemd reports, via cat/echo into /sys/fs/cgroup/pids/system.slice/cron.service/pids.max. This confirms that systemd actually changes cgroup settings on daemon-reload )

added 1 commit

• 6ad75ea1 - fixup

Compare with previous version

Hi @kirr ,

You are right, there is no need to restart cron (I didn't know that systemd could update the service definition on live, without a restart).

I've pushed this change, with the comment in the override.conf file.

added 1 commit

• c7d02d05 - fixup

Compare with previous version

On debian stretch (current stable), the changes don't apply to cron service without explicitely telling systemd to restart it.

# This doesn't work for ansible version < 2.4
systemd: daemon_reload=yes

https://docs.ansible.com/ansible/latest/modules/systemd_module.html#systemd-module

I've kept the old version which force the restart of cron when its systemd service definition is updated (I tried with state=started also, but it didn't work). I left a comment in the playbook.

Hi @Nicolas thanks also for providing a patch. I'm OK with this. Could you squash the 2 commits ? If you don't have time, I'll do it before merging.

We will try to run the upgrader soon

added 1 commit

• 77e7e64a - vifib-server: set the number of subprocesses for cron unlimited

Compare with previous version

Hi @tomo ! I've squashed and pushed, you can merge the MR.

Good luck if you upgrade on a Friday ;)

mentioned in commit 50da7401

merged