Is your feature request related to a problem? Please describe.
The core issue at hand is that additional ExecStartPre (and the others) instructions will always be executed after the ones specified in the vendor file.
Now if you would like (or need to) add one of those instructions to run before the vendor ones you currently are out of luck to do that in a nice way.
An example use case would be the following:
Imagine /var/log has become a volatile storage and gets wiped with every reboot.
On the other hand we have the nginx service which expects to be able to create file in its /var/log/nginx dir.
Now on that system without any modification nginx will always fail to start.
A possible solution would be to create a drop in config for the nginx service along the lines of:
[Service]
ExecStartPre=+/bin/mkdir -p /var/log/nginx
ExecStartPre=+/bin/chown -R root:adm /var/log/nginx
Now that would work in this case if nginx didn't have a ExecStartPre instruction of its own. One which checks for the existance of the folder in the first place (ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;').
The only solution left at this point is to modify the drop in config to reset the ExecStartPre instructions (with ExecStartPre=) and to order the instructions accordingly:
[Service]
ExecStartPre=
ExecStartPre=+/bin/mkdir -p /var/log/nginx
ExecStartPre=+/bin/chown -R root:adm /var/log/nginx
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
While this will now work I feel it defeats the purpose of drop in files. Namely being resitant to changes in vendor files. Because if the nginx vendor file would ever change its ExecStartPre instruction, it would remain outdated until the admin notices it and updates it as well.
Describe the solution you'd like
While I am not sure of how exactly the markup for prioritized ExecStartPre, ExecStartPost, ExecStopPre and ExecStopPost should look like, a suggestion would be something like this:
[Service]
!ExecStartPre=+/bin/mkdir -p /var/log/nginx
!ExecStartPre=+/bin/chown -R root:adm /var/log/nginx
Or in other words a way to mark those instructions in a way that systemd executes them before the ones in the vendor script.
Describe alternatives you've considered
The only alternative I could think of is the one layed out in the second snippet. Though doing it like that means losing one of the key points of drop in configs: That they don't care about changes in the vendor configs (for the most part at least).
Is your feature request related to a problem? Please describe.
The core issue at hand is that additional
ExecStartPre(and the others) instructions will always be executed after the ones specified in the vendor file.Now if you would like (or need to) add one of those instructions to run before the vendor ones you currently are out of luck to do that in a nice way.
An example use case would be the following:
Imagine
/var/loghas become a volatile storage and gets wiped with every reboot.On the other hand we have the nginx service which expects to be able to create file in its
/var/log/nginxdir.Now on that system without any modification nginx will always fail to start.
A possible solution would be to create a drop in config for the nginx service along the lines of:
Now that would work in this case if nginx didn't have a
ExecStartPreinstruction of its own. One which checks for the existance of the folder in the first place (ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;').The only solution left at this point is to modify the drop in config to reset the
ExecStartPreinstructions (withExecStartPre=) and to order the instructions accordingly:While this will now work I feel it defeats the purpose of drop in files. Namely being resitant to changes in vendor files. Because if the nginx vendor file would ever change its
ExecStartPreinstruction, it would remain outdated until the admin notices it and updates it as well.Describe the solution you'd like
While I am not sure of how exactly the markup for prioritized
ExecStartPre,ExecStartPost,ExecStopPreandExecStopPostshould look like, a suggestion would be something like this:Or in other words a way to mark those instructions in a way that systemd executes them before the ones in the vendor script.
Describe alternatives you've considered
The only alternative I could think of is the one layed out in the second snippet. Though doing it like that means losing one of the key points of drop in configs: That they don't care about changes in the vendor configs (for the most part at least).