RFE: Add template specifier for path to unit file #6308
Comments
|
Hmm. You could easily have a script in the git repo which would generate the unit file with the right path and call |
|
I have exactly the same use case and would like to vote for the proposed enhancement as well. A lot of people deploy software using their SCMs, including things like While of course each and every project could implement custom scripts, this seems like redundant and error prone work to me. Additionally, dynamically generating those scripts makes deployment in general more difficult: Where should those generated scripts be stored? In the working copy and if so, should it be versioned by users or not? How about updates, which might change some template unit file? With custom generated unit files the generator might need to run again, which would not be needed if there's only one versioned file containing all the needed specifiers already. So, in my opinion, this is not a fringe case anymore, but instead becomes more and more common and additional format specifiers would make |
|
Yes same use-case here |
|
And how would those specifiers expand in drop-ins? |
|
AFAIK there are two forms of drop-ins, one overriding a file completely and the other overriding individual settings. So it depends on how the specifier is defined in the end and which override is used: If a file is overridden completely and the specifier implements the easiest case of resolving to the unit file where it is defined in, do the same with overrides and assume users know what they are doing. In case of overriding individual settings, I would expect that if the setting containing the specifier is NOT overridden, it resolves to the file in which it is actually specified. If it is overridden, assume the same argument as before and resolve based on the overriding file. Depending on how overriding individual settings is implemented, resolving based on the original file might be difficult of course. But don't make things too complicated, this is a 99 % vs. 1 %-scenario. In 99 % of the use-cases things won't be overridden and users can write "wrong" unit files anyway for any reason. Drop-ins might simply be not supported well like the whole use-case described in this issue is currently. In the end, even without proper support for drop-ins things like |
|
Another vote in favor here. For units that are not overridden it's possible to determine the source file path from the |
|
A related feature would be support of executive paths relative to |
|
I'd like to second and elaborate on what @ams-tschoening said about this. I try to have my enabled units link directly to source files in a git checkout directory that is the deployment. If forced to override the contents of the source file as described by @keszybz then all or part of the source file becomes inoperative. It is MUCH more useful to have symbols (either %x or ${x}), in the source file that get replaced by path components at runtime. That's available for the home dir with %h and ${HOME}. Why can't it be provided for the location of the source file as well? As it stands, the .path units are almost useless because so much has to be hard-coded a priori in the source file that the deployment becomes far too brittle. |
|
Also another way which help reduce errors Another words - it help if we need to take some actions on the same folder. |
|
I'm also looking for a way to not having to repeat the working directory path in |
|
I'm onboarding @alexlzhu and am proposing he works on a feature |
…xecuted by Exec*= should be found │A way to specify a directory where binaries executed by Exec*= should be found (in addition to the PATH set by systemd). Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…xecuted by Exec*= should be found Closes systemd#6308
…ies executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change adds the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…ies executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change adds the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…ies executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change adds the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…ies executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change adds the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…to which binaries executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change adds the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…to which binaries executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change adds the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…to which binaries executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change implements the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…to which binaries executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change implements the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
…to which binaries executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change implements the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes #6308
|
How does the new This should be reopened in my opinion, |
|
I agree that the |
There is %I which you can use to pass arbitrary stuff as the instance name: And then you can run like so: But actually looking at this issue again you could have used specifiers and templates to do this even without ExecSearchPath= to pass arbitrary paths: ExecSearchPath= allows you to use drop-in overrides though which is nicer if you already know which paths to use. If you really want a specifier specifically for working directory though we can reopen but I agree with keszybz that it's a bit of a fringe use case. |
|
If a service is set for auto-start at boot would the |
Besides the reboot-question, this already looks like an ugly hack.
Only if one ignores the LIKE-votes and somewhat detailed comments explaining absolutely valid and pretty standard use-cases. :-/ |
Yes if you do |
|
Edit: Seems my post and the reopening crossed each other, thanks @anitazha for reopening! I would indeed agree that the linked PR does not solve my original request, or even improve it at all (it does solve #6308 (comment) and #6308 (comment), but IMHO those are really different problems from the original issue). I would suggest reopening this. Of course, this is a bit of a fringe case, so closing this as wontfix would be a valid path (I personally would prefer adding the specifier, obviously, but I can see that choices must be made in what to implement and what to leave out), but then I would suggest reopening this and then closing it with a clear wontfix statement, for clarity. As for the
AFAIU, yes, though you'd need |
…to which binaries executed by Exec*= should be found Currently there does not exist a way to specify a path relative to which all binaries executed by Exec should be found. The only way is to specify the absolute path. This change implements the functionality to specify a path relative to which binaries executed by Exec*= can be found. Closes systemd#6308
Fixes systemd#6308: people want to be able to link a unit file via 'systemctl enable' from a git checkout or such and refer to other files in the same repo. The new specifiers make that easy. %y/%Y is used because other more obvious choices like %d/%D or %p/%P are not available because at least on of the two letters is already used. The new specifiers are only available in units. Technically it would be trivial to add then in [Install] too, but I don't see how they could be useful, so I didn't do that. I added both %y and %Y because both were requested in the issue, and because I think both could be useful, depending on the case. %Y to refer to other files in the same repo, and %y in the case where a single repo has multiple unit files, and e.g. each unit has some corresponding asset named after the unit file.
|
@matthijskooijman (and anyone else who commented): please check if #22195 DTRT for you. |
Fixes systemd#6308: people want to be able to link a unit file via 'systemctl enable' from a git checkout or such and refer to other files in the same repo. The new specifiers make that easy. %y/%Y is used because other more obvious choices like %d/%D or %p/%P are not available because at least on of the two letters is already used. The new specifiers are only available in units. Technically it would be trivial to add then in [Install] too, but I don't see how they could be useful, so I didn't do that. I added both %y and %Y because both were requested in the issue, and because I think both could be useful, depending on the case. %Y to refer to other files in the same repo, and %y in the case where a single repo has multiple unit files, and e.g. each unit has some corresponding asset named after the unit file.
Fixes systemd#6308: people want to be able to link a unit file via 'systemctl enable' from a git checkout or such and refer to other files in the same repo. The new specifiers make that easy. %y/%Y is used because other more obvious choices like %d/%D or %p/%P are not available because at least on of the two letters is already used. The new specifiers are only available in units. Technically it would be trivial to add then in [Install] too, but I don't see how they could be useful, so I didn't do that. I added both %y and %Y because both were requested in the issue, and because I think both could be useful, depending on the case. %Y to refer to other files in the same repo, and %y in the case where a single repo has multiple unit files, and e.g. each unit has some corresponding asset named after the unit file.
Fixes systemd#6308: people want to be able to link a unit file via 'systemctl enable' from a git checkout or such and refer to other files in the same repo. The new specifiers make that easy. %y/%Y is used because other more obvious choices like %d/%D or %p/%P are not available because at least on of the two letters is already used. The new specifiers are only available in units. Technically it would be trivial to add then in [Install] too, but I don't see how they could be useful, so I didn't do that. I added both %y and %Y because both were requested in the issue, and because I think both could be useful, depending on the case. %Y to refer to other files in the same repo, and %y in the case where a single repo has multiple unit files, and e.g. each unit has some corresponding asset named after the unit file.
|
@keszybz Thanks! I haven't tested the PR, but from the documentation it seems like it would indeed fix my case exactly. Awesome! |
|
@matthijskooijman Did fragment specifiers resolve your use-case in the end? I would like to use fragment specifiers in my systemd configs as well, but I can't find any information whatsoever as to what they even are in context of systemd, let alone how to use them. The only mention of fragments related to unit files I can find are in this PR that implements fragment specifiers and the documentation it adds. And that's it. Could you please direct me to what you found out about them? |
I'm not sure I've actually tested yet, but from what I see from the docs, they should solve my case.
They are documented in the systemd.unit manpage, in the "FRAGMENT SPECIFICERS" section. |
|
For future reference, the |
Submission type
I would like to see one or two extra specifiers to be used in unit files that would expand to:
This would help to support bits of software that are not installed into a fixed place, without having to hardcode paths into the unit file.
E.g. consider a git clone of a bit of software. I cloned this into
/home/matthijs/foo, but this could be any other path. To start a daemon from that directory, I'm including a service file into the git repo, that looks like this:After making the git clone, I can set this up using:
This makes the needed links in
/etc/systemdto make this service run.However, the service file hardcodes the path to the git checkout, which makes it not so suitable for inclusion in the git repository itself.
If, for example,
%dwould refer to the unit file's directory, I would be able to use:and this service file would work regardless of where the git checkout
was made.
The text was updated successfully, but these errors were encountered: