Thanks, that workaround fixes it indeed.<br><br><br>Verzonden met ProtonMail Mobile<br><br><br><br>-------- Oorspronkelijk bericht --------<br>Aan 6 feb. 2019 19:19, Benjamin Drung < benjamin.drung@cloud.ionos.com > schreef:<blockquote class="protonmail_quote"><br><p dir="ltr">reassign 919231 systemd 240-5<br>
retitle 919231 CacheDirectory/StateDirectory does not change owner/group<br>
thanks</p>
<p dir="ltr">Hi Stijn,</p>
<p dir="ltr">your bug description was enough for me to reproduce this misbehavior<br>
and tracked it down to systemd not behaving like the documentation<br>
describes:</p>
<p dir="ltr">StateDirectory=, CacheDirectory=<br>
Except in case of ConfigurationDirectory=, the innermost specified<br>
directories will be owned by the user and group specified in User=<br>
and Group=. If the specified directories already exist and their<br>
owning user or group do not match the configured ones, all files<br>
and directories below the specified directories as well as the<br>
directories themselves will have their file ownership recursively<br>
changed to match what is configured. As an optimization, if the<br>
specified directories are already owned by the right user and<br>
group, files and directories below of them are left as-is, even<br>
if they do not match what is requested.</p>
<p dir="ltr">The salt-master systemd service is configured to use<br>
/var/lib/salt/pki/master and /var/cache/salt/master as state and cache<br>
directory. salt should change the ownership, but it does not. Steps to<br>
reproduce:</p>
<p dir="ltr">Take a minimal Debian 9 installation and:</p>
<p dir="ltr">```<br>
root@debian:~# apt install salt-master<br>
root@debian:~# sed -i 's/stretch/buster/g' /etc/apt/sources.list<br>
root@debian:~# apt upgrade<br>
[...]<br>
Setting up salt-master (2018.3.3+dfsg1-2) ...<br>
Installing new version of config file /etc/salt/master ...<br>
Job for salt-master.service failed because the control process exited<br>
with error code.<br>
See "systemctl status salt-master.service" and "journalctl -xe" for<br>
details.<br>
invoke-rc.d: initscript salt-master, action "restart" failed.<br>
● salt-master.service - The Salt Master Server<br>
Loaded: loaded (/lib/systemd/system/salt-master.service; enabled;<br>
vendor preset: enabled)<br>
Active: failed (Result: exit-code) since Wed 2019-02-06 16:16:37<br>
UTC; 8ms ago<br>
Docs: man:salt-master(1)<br>
file:///usr/share/doc/salt/html/contents.html<br>
<a href="https://docs.saltstack.com/en/latest/contents.html">https://docs.saltstack.com/en/latest/contents.html</a><br>
Process: 31417 ExecStart=/usr/bin/salt-master (code=exited,<br>
status=13)<br>
Main PID: 31417 (code=exited, status=13)</p>
<p dir="ltr">Feb 06 16:16:37 debian systemd[1]: Starting The Salt Master Server...<br>
Feb 06 16:16:37 debian salt-master[31417]: Failed to create directory<br>
path "/var/lib/salt/pki/master/minions" - [Errno 13] Permission denied:<br>
'/var/lib/salt/pki/master/minions'<br>
Feb 06 16:16:37 debian systemd[1]: salt-master.service: Main process<br>
exited, code=exited, status=13/n/a<br>
Feb 06 16:16:37 debian systemd[1]: salt-master.service: Failed with<br>
result 'exit-code'.<br>
Feb 06 16:16:37 debian systemd[1]: Failed to start The Salt Master<br>
Server.<br>
dpkg: error processing package salt-master (--configure):<br>
installed salt-master package post-installation script subprocess<br>
returned error exit status 1<br>
[...]<br>
```</p>
<p dir="ltr">Instead of doing an upgrade test, you can just do the test on testing<br>
by stopping salt-master, changing the permission to root and starting<br>
salt-master.</p>
<p dir="ltr">```<br>
root@debian:~# systemctl cat salt-master.service<br>
# /lib/systemd/system/salt-master.service<br>
[Unit]<br>
Description=The Salt Master Server<br>
Documentation=man:salt-master(1)<br>
file:///usr/share/doc/salt/html/contents.html<br>
<a href="https://docs.saltstack.com/en/latest/contents.html">https://docs.saltstack.com/en/latest/contents.html</a><br>
After=network.target</p>
<p dir="ltr">[Service]<br>
LimitNOFILE=100000<br>
Type=notify<br>
NotifyAccess=all<br>
ExecStart=/usr/bin/salt-master<br>
User=salt<br>
Group=salt<br>
CacheDirectory=salt/master<br>
RuntimeDirectory=salt<br>
StateDirectory=salt/pki/master</p>
<p dir="ltr">[Install]<br>
WantedBy=multi-user.target<br>
root@debian:~# ls -ld /var/lib/salt /var/lib/salt/pki<br>
/var/lib/salt/pki/master<br>
drwxr-xr-x 3 salt salt 4096 Feb 6 16:16 /var/lib/salt<br>
drwxr-xr-x 3 root root 4096 Feb 6 16:16 /var/lib/salt/pki<br>
drwx------ 7 root root 4096 Feb 6 16:10 /var/lib/salt/pki/master<br>
root@debian:~# ls -ld /var/cache/salt /var/cache/salt/master<br>
drwxr-xr-x 3 root root 4096 Feb 6 16:10 /var/cache/salt<br>
drwxr-xr-x 8 root root 4096 Feb 6 16:11 /var/cache/salt/master<br>
rroot@debian:~# dpkg -l | grep systemd | sed 's/ \+amd64 .*$//'<br>
ii libnss-systemd:amd64 240-5<br>
ii libpam-systemd:amd64 240-5<br>
ii libsystemd0:amd64 240-5<br>
ii python-systemd 234-2+b1<br>
ii python3-systemd 234-2+b1<br>
ii systemd 240-5<br>
ii systemd-sysv 240-5<br>
```</p>
<p dir="ltr">The workaround is to manually change the owner/group to salt:</p>
<p dir="ltr">root@debian:~# chown -R salt:salt /var/lib/salt/pki/master /var/cache/salt/master<br>
root@debian:~# systemctl start salt-master</p>
<p dir="ltr">--<br>
Benjamin Drung<br>
System Developer<br>
Debian & Ubuntu Developer</p>
<p dir="ltr">1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany<br>
E-mail: <a href="mailto:benjamin.drung@cloud.ionos.com">benjamin.drung@cloud.ionos.com</a> | Web: <a href="http://www.ionos.de">www.ionos.de</a></p>
<p dir="ltr">Head Office: Berlin, Germany<br>
District Court Berlin Charlottenburg, Registration number: HRB 125506 B<br>
Executive Management: Christoph Steffens, Matthias Steinberg, Achim<br>
Weiss</p>
<p dir="ltr">Member of United Internet</p>
</div>