Re: [HTCondor-users] systemd interfering with Condor job cgroups

[Thomas Hartmann <thomas.hartmann@xxxxxxx>]

Hi Greg,

in the end without the delegation, my steps to shred the sub-slices were
reduced to
* adding a new basic unit to /etc/systemd/system (userland units and
slices behaved differently)
* reload the units aka 'systemd daemon-reload'
* and then start the fresh unit

worked for me at least on CentOS 7.5.1804 and systemd-219-57

I have no idea, why a unit restart does not reliably trigger the
behaviour - but only a new unit. It should be somewhat the same for
systemd?? Probably only Poettering knows... ;)

Interestingly, systemd-cgls showed systemd's cgoup view during all
steps, i.e., ignoring(??) the kernel's cgroup hierarchy.
Anyway, with delegation on, the sub-slices are still not known according
to systemd-cgls and all PIDs hang below the condor slice -- but at least
systemd does not care anymore for them

Cheers,
  Thomas

On 2018-06-29 17:13, Greg Thain wrote:
> 
> Thomas:
> 
> How are you reproducing the problem? I can see it happening from time
> to time, but systemctl restart random_service doesn't seem to trigger
> it. Do you have some magic that reliably reproduces the escape?
> 
> Thanks,
> 
> -greg

[1]
[Unit]
Description=do not much

[Service]
User=root
Group=root
Type=oneshot
StandardOutput=journal
StandardError=journal
ExecStart=/bin/ls

[Install]
WantedBy=multi-user.target

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature