Description of problem: The general idea goes something like this.. Admin runs "systemctl edit my.service" 1. systemd reads the $EDITOR variable from shell if undefined falls back to use vi(m) which is posix standard ( I think ed is as well but hey who remembers and used ed ;) ) three use cases I can think of when admin wants edit units 1. An admin wants to create new unit file. ( empty template based on ending kind a must have for timer units for users ) 2. An admin wants to make minor changes to unit file ( .include ) 3. An admin wants to make major changes to unit file ( copy unit ) 1. a new file is opened based on a unit template like would open the file /etc/systemd/system/my.service with .service template [Unit] Description= Before= After= [Service] Type= PIDFile=/var/run/ ExecStarPre= ExecStart= ExecReload= ExecStop= ... [Install] WantedBy=multi-user.target 2. an file is opened in /etc/systemd/system/my.service containing only .include reference and [Service] 3. my.service is copied to /etc/systemd/system/ directory 4. once file is saved systemd is reload to pick up the changes. systemctl edit my.service covers both first and second use cases as in if file does not exist (1) then create an new one based on template. If file exist open it with .include file Usecase 3 should be seperated command something like "systemctl edit my.service --full" to copy/edit an entire unit. I do believe we need something like 1 for timer units to provide similar if not easier cron experience as in user can just run systemctl edit my.timer and it provides him with a timer unit skeleton which he essentially just has to specify the path to what he's going to execute and the time he's going to do it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
With the addition of "<unit>.d" files, this probably should be a completely new tool.
Well I would think we would not want to add another tool but rather focus on having administrators always just having to use systemctl ( in this case systemctl -e ) rather then introducing another tool to learn about ( something like systemc-edit foo.unit ) remind me again what problem we where solving with introducing <unit>.d directories since we have started to introduce a complete new complexity on top of the maze of symbolic links for administrators to learn. As things seams are heading we need to restructure our /etc/system directory in not to distant future to keep things from being to complex and hard to use.
Created attachment 733706 [details] Custom unit design Threw together how I mostly see how this should be implemented and solved in general when users edit or add units themselves
(In reply to comment #3) > Created attachment 733706 [details] > Custom unit design > > Threw together how I mostly see how this should be implemented and solved in > general when users edit or add units themselves Ofcourse the time template should default it's [Install] section to the timer.target as I mentioned we needed in BRNO
I would say, we should always present admin with union of all config fragments. In case of new unit with template. On save tool should figure out for each changed configuration line where it comes from and override it in an appropriate location. I think this should be handled in separate tool rather than in systemctl.
Done upstream in http://cgit.freedesktop.org/systemd/systemd/commit/?id=7d4fb3b1c5.
It can only edit units for the moment. No unit creation based on a template has been implemented.