Bug 891748 - ExecStart isn't properly overriden when using .include
Summary: ExecStart isn't properly overriden when using .include
Status: CLOSED DUPLICATE of bug 756787
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-03 21:08 UTC by Bill Nottingham
Modified: 2014-03-17 03:32 UTC (History)
10 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-01-08 13:40:31 UTC


Attachments (Terms of Use)

Description Bill Nottingham 2013-01-03 21:08:57 UTC
Description of problem:

From the man page:
       ExecStart=
...
           This option may not
           be specified more than once, except when Type=oneshot is used in
           which case more than one ExecStart= line is accepted which are then
           invoked one by one, sequentially in the order they appear in the
           unit file.

However, in testing:
[root@nostromo ~]# cd /run/systemd/system
[root@nostromo system]# cat getty@.service
.include /lib/systemd/system/getty@.service

[Service]
ExecStart=-/sbin/agetty -f /run/test-issue --noclear %I 38400 linux
[root@nostromo system]# systemctl daemon-reload
[root@nostromo system]# systemctl show getty@tty5.service | grep ExecStart
ExecStart={ path=/sbin/agetty ; argv[]=/sbin/agetty --noclear %I 38400 linux ; ignore_errors=yes ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
ExecStart={ path=/sbin/agetty ; argv[]=/sbin/agetty -f /run/test-issue --noclear %I 38400 linux ; ignore_errors=yes ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }

Either the docs are wrong, or the implementation is buggy. (getty@ is of Type idle, not oneshot.)

Version-Release number of selected component (if applicable):

systemd-195-10.fc18.x86_64

How reproducible:

100%

Steps to Reproduce:
1. see above
  
Actual results:

ExecStart is extended with a second command

Expected results:

ExecStart is overridden

Additional info:

Copying the unit file wholesale and making the change works as expected.

Comment 1 Michal Sekletar 2013-01-07 13:47:52 UTC
I think this is an expected behavior. I believe unit is in inactive state because of load error and appropriate message is logged in journal. AFAIK it is not possible to override ExecStart=.

Comment 2 Michal Schmidt 2013-01-07 16:58:00 UTC
Is this bug 756787?

Comment 3 Michal Sekletar 2013-01-08 09:59:40 UTC
(In reply to comment #2)
> Is this bug 756787?

I believe so. I think we should close this bug, since we already keep track of the issue.

Comment 4 Michal Schmidt 2013-01-08 13:40:31 UTC

*** This bug has been marked as a duplicate of bug 756787 ***


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