2

I have a test systemd service that I am testing. I have test.service which looks like this

[Unit]
Description=Dovid Demo Service
After=mariadb.service
Requires=mariadb.service

[Service]
ExecStart=/home/dovid/test.sh
User=dovid
Group=dovid

[Install]
WantedBy=default.target

If I do

systemctl start test

It will first start MariaDB and then start my script. However if I have MariaDB masked (I did systemctl mask mariadb) then MariaDB wont start yet systemd will start up test.sh. Shouldn't it fail because start a required process which in this case is MariaDB?

3

This is a bug in systemd. I have filed a bug report and done analysis of what is wrong here: https://github.com/systemd/systemd/issues/11338

That issue manifests here as the target gains a Wants= on the unit that Requires= a masked unit. The transaction is built and systemd has already added a job for the anchor unit, its Wants= dependency, and does not remove it when it gets -ERFKILL in your case, and propagating this up to the function called for UNIT_WANTS ignores it (as it isn't a fatal error), so you end up having the unit started even when required unit is masked.

This happens with many other cases, like RequiresMountsFor= for non-existent paths, etc. Same for BindsTo= as well.

Doing traversal from the bottom up is something I played around with, but that results in another issue: if some unit Requires=existing.service non-existent.service, it will still queue a spurious job, so this adding of jobs needs to be atomic at some level. Moreover, it may not enqueue a spurious job, depending on the order you specify things in.

Anyway, consider bumping that GitHub issue, and explain how you're hitting it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.