Bug 906824 - RFE: introduce systemctl edit $unit
RFE: introduce systemctl edit $unit
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: systemd-RFE 959971
  Show dependency treegraph
 
Reported: 2013-02-01 10:28 EST by Jóhann B. Guðmundsson
Modified: 2015-03-13 01:02 EDT (History)
12 users (show)

See Also:
Fixed In Version: systemd-218-5.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-13 01:02:37 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Custom unit design (3.28 KB, text/plain)
2013-04-10 09:56 EDT, Jóhann B. Guðmundsson
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2013-02-01 10:28:30 EST
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:
Comment 1 Harald Hoyer 2013-04-10 07:02:02 EDT
With the addition of "<unit>.d" files, this probably should be a completely new tool.
Comment 2 Jóhann B. Guðmundsson 2013-04-10 07:34:38 EDT
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.
Comment 3 Jóhann B. Guðmundsson 2013-04-10 09:56:37 EDT
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
Comment 4 Jóhann B. Guðmundsson 2013-04-10 10:07:59 EDT
(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
Comment 6 Michal Sekletar 2013-06-29 12:44:30 EDT
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.
Comment 7 Zbigniew Jędrzejewski-Szmek 2014-11-29 13:58:53 EST
Done upstream in http://cgit.freedesktop.org/systemd/systemd/commit/?id=7d4fb3b1c5.
Comment 8 Ronny Chevalier 2014-11-29 14:39:36 EST
It can only edit units for the moment. No unit creation based on a template has been implemented.

Note You need to log in before you can comment on or make changes to this bug.