RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1000383 - systemctl enable/disable of unit does not respect default target.
Summary: systemctl enable/disable of unit does not respect default target.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 959971 1297395
TreeView+ depends on / blocked
 
Reported: 2013-08-23 10:50 UTC by Petr Sklenar
Modified: 2016-10-20 07:03 UTC (History)
8 users (show)

Fixed In Version: systemd-219-30.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-20 07:03:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Petr Sklenar 2013-08-23 10:50:35 UTC
Description of problem:
enable/disable of any unit does not respect current default target.

Version-Release number of selected component (if applicable):
systemd-206-4.el7.x86_64

How reproducible:
always

Steps to Reproduce:

1. install @base

ls -la /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 37 Aug 22 07:55 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

2. install lightDM window manager

3. systemctl enable lightdm.service
ln -s '/usr/lib/systemd/system/lightdm.service' '/etc/systemd/system/display-manager.service'

4. reboot the machine

5. systemctl is-enabled lightdm.service
enabled


Actual results:
lightdm is not running
systemctl enable/disable does not care of current and default target

Expected results:
lightdm is running

systemctl enable/disable/is-enabled says if unit is really enabled for defined target.
It could show the name of the target for its really enabled.

Additional info:
the reason is that all the time is my default target not graphical but some of the text one.
Systemd scripts writes results for different settings, not current. There is no indication about that.

Comment 1 Tomas Dolezal 2013-08-23 10:58:45 UTC
In my humble opinion it would be great if systemd shown _at least_ message like: "Enabled for <list of relevant targets>". Unfortunatelly, there is pending bug 627277 which would improve UX much more in conjuntion with this one.

Comment 3 Lukáš Nykrýn 2013-08-26 14:13:16 UTC
I think that current behavior is feature not a bug. lightdm.service creates (overwrites) /etc/systemd/system/display-manager.service which is required by graphical target. We assume that this is what user wants in most of the cases.

(In reply to Tomáš Doležal from comment #1)
> In my humble opinion it would be great if systemd shown _at least_ message
> like: "Enabled for <list of relevant targets>". Unfortunatelly, there is
> pending bug 627277 which would improve UX much more in conjuntion with this
> one.

bug 627277 is fixed. We have now something like systemctl set-default and get-default. And if you want to see on which targets will be the unit launched you can use:
systemctl list-dependencies --reverse display-manager.service
display-manager.service
└─graphical.target

If you want to enable the service on different targets, you can create symlink manually, add the dependency through drop-in or rewrite it through /etc.

I think that this bug should be closed as NOTABUG or WORKSFORME, but I am open to any objections or questions.

Comment 4 Lukáš Nykrýn 2013-08-26 14:18:06 UTC
One mistake, in the case that /etc/systemd/system/display-manager.service already exists it is not overwritten, but the systemctl command fails. You have to disable the current one first.

Comment 5 Karel Volný 2013-08-26 15:39:07 UTC
(In reply to Lukáš Nykrýn from comment #3)
> I think that current behavior is feature not a bug. lightdm.service creates
> (overwrites) /etc/systemd/system/display-manager.service which is required
> by graphical target. We assume that this is what user wants in most of the
> cases.

while this is sane assumption for this service, the problem is that the user is not informed about what really happens and can hardly change that

maybe I'm old fashioned, but I'm used to fact that the configuration utilities change the current configuration (restart may be needed, but other that that, it applies) - if systemctl touches something that is not used, I'd really appreciate some warning that my change won't apply

> And if you want to see on which targets will be the unit
> launched you can use:
> systemctl list-dependencies --reverse display-manager.service
> display-manager.service
> └─graphical.target

but this lists all dependencies (and just dependencies), so it is not that easy to figure out the targets list and what are targets representing runlevel equivalents and what are just helpers, and what is the relation to the actual/default target

oh, and it needs the service to be actually enabled, it won't tell the list where the service will be enabled before enabling it

> If you want to enable the service on different targets, you can create
> symlink manually, add the dependency through drop-in or rewrite it through
> /etc.

that doesn't seem exactly user-friendly ...

the old chkconfig command has the --level option which allows to specify runlevels, so not having an equivalent to enumerate targets is not just unfriendly but a functional regression

Comment 6 Lukáš Nykrýn 2013-08-27 07:41:51 UTC
> while this is sane assumption for this service, the problem is that the user
> is not informed about what really happens and can hardly change that
Vašek is going to write some more user-friendly messages to the systemctl so that will fix this issue.

> maybe I'm old fashioned, but I'm used to fact that the configuration
> utilities change the current configuration (restart may be needed, but other
> that that, it applies) - if systemctl touches something that is not used,
> I'd really appreciate some warning that my change won't apply
I am not sure if I understand you correctly, the change is applied. In the case of lightdm and similar enable does not mean 'start on specific target', but 'set it as the default display manager', which I think is again more user-friendly and robust way. Again there should be a better message, but that is solved in different bug.
 
> but this lists all dependencies (and just dependencies), so it is not that
> easy to figure out the targets list and what are targets representing
> runlevel equivalents and what are just helpers, and what is the relation to
> the actual/default target
> 
> oh, and it needs the service to be actually enabled, it won't tell the list
> where the service will be enabled before enabling it

Yes, the dependency approach instead of old runlevels could be a little bit harder to administer at first, but it is much more flexible. You can have a service, that is started by another service, which has the socket-activation. And unfortunately you can't say which targets are the "main ones". You can boot to any unit you want. So the list-dependencies is the best way here.

> the old chkconfig command has the --level option which allows to specify
> runlevels, so not having an equivalent to enumerate targets is not just
> unfriendly but a functional regression
There is a "add-wants" command is our TODO, but for me this request was obsolete by the introduction of drop-in files. But I will give it a second thought.

So to conclude, we are going to write some more user-friendly output to systemctl, that user will be informed what happened instead of command which was executed and I will consider to add a command to enable service on specific runlevel.
For me the initial report by Petr is not a bug, so I am closing this one. Please if you have some additional suggestions, questions or complaints please create a new one or you are welcome to discuss them on our upstream mailing list.

Comment 7 Karel Volný 2013-12-12 16:15:13 UTC
(In reply to Lukáš Nykrýn from comment #6)
> > while this is sane assumption for this service, the problem is that the user
> > is not informed about what really happens and can hardly change that
> Vašek is going to write some more user-friendly messages to the systemctl so
> that will fix this issue.

I fail to see how _any_ message could fix e.g. the functional regression in comparison with chkconfig mentioned in comment #5?

> > maybe I'm old fashioned, but I'm used to fact that the configuration
> > utilities change the current configuration (restart may be needed, but other
> > that that, it applies) - if systemctl touches something that is not used,
> > I'd really appreciate some warning that my change won't apply
> I am not sure if I understand you correctly, the change is applied. In the
> case of lightdm and similar enable does not mean 'start on specific target',
> but 'set it as the default display manager', which I think is again more
> user-friendly and robust way. Again there should be a better message, but
> that is solved in different bug.

"is applied" = "has an effect on the thing that is the subject of the change"

i.e., if displaymanager is enabled, it should be started (on next suitable occasion like reboot), not just that a config file/symlink/whatever is changed but the displaymanager still does not start

> > but this lists all dependencies (and just dependencies), so it is not that
> > easy to figure out the targets list and what are targets representing
> > runlevel equivalents and what are just helpers, and what is the relation to
> > the actual/default target
> > 
> > oh, and it needs the service to be actually enabled, it won't tell the list
> > where the service will be enabled before enabling it
> 
> Yes, the dependency approach instead of old runlevels could be a little bit
> harder to administer at first, but it is much more flexible. You can have a
> service, that is started by another service, which has the
> socket-activation. And unfortunately you can't say which targets are the
> "main ones". You can boot to any unit you want. So the list-dependencies is
> the best way here.

I simply do not understand how the "flexibility" you talk about helps to fix the issue I mention - "it won't tell the list where the service will be enabled before enabling it"

and in addition, I'm still pretty sure that there are admins (/me being an example) who would appreciate some simple way to see which targets are to be used instead of runlevels (and I don't mean that in the sense "old 0 runlevel is now poweroff.target" but rather "you may want to run your system in graphical.target, while you don't want to end up in printer.target as it is just helper")

> > the old chkconfig command has the --level option which allows to specify
> > runlevels, so not having an equivalent to enumerate targets is not just
> > unfriendly but a functional regression
> There is a "add-wants" command is our TODO,

bug/rfe #?

> but for me this request was obsolete by the introduction of drop-in files.

the fact that these has been introduced doesn't help the issue that systemctl does not provide functionality similar to chkconfig --level

> So to conclude, we are going to write some more user-friendly output to
> systemctl, that user will be informed what happened instead of command which
> was executed

> and I will consider to add a command to enable service on specific runlevel.

cool, so ...

> For me the initial report by Petr is not a bug, so I am closing this one.

... I just don't understand why do you close this one when you haven't dealt with it yet?

you can change the subject, you can push the version forward, you can mark it FutureFeature, or do anything you find appropriate for this to serve for tracking the issue until you submit the code, the package gets built and pushed into the distribution

> Please if you have some additional suggestions, questions or complaints
> please create a new one

see above, why?

- if this one doesn't suit you even after fixing all the interesting bz fields and whatever, do you think that a new bug filed by us would be any better in this regard?

if you _really need_ a new bug, why don't you just file it to your taste and then mark this one duplicate?

> or you are welcome to discuss them on our upstream mailing list.

sorry, but upstream mailing list is not a part of our workflow; we (QE) have accounts in RH Bugzilla, not at any random upstream resource for all the packages in the distro, and the same goes for all the tracking and whatever - e.g. planning the capacity ...

if you think this really needs to be bringed elsewhere, please act as a proxy

Comment 8 Ludek Smid 2014-06-26 10:47:47 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Comment 9 Ludek Smid 2014-06-26 11:16:24 UTC
The comment above is incorrect. The correct version is bellow.
I'm sorry for any inconvenience.
---------------------------------------------------------------

This request was NOT resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you need
to escalate this bug.

Comment 15 Lukáš Nykrýn 2015-05-07 10:10:45 UTC
We should try to make enable messages even more readable for admin. Also it would probably make sense if is-enabled could print iformation about target where is this enabled.

Comment 16 Jan Synacek 2016-10-19 08:22:17 UTC
To sum up the original issue:

(In reply to Petr Sklenar from comment #0)

> 3. systemctl enable lightdm.service
> ln -s '/usr/lib/systemd/system/lightdm.service'
> '/etc/systemd/system/display-manager.service'

# systemctl enable lightdm
Failed to execute operation: File exists

There could be an additional, more user-friendly message, but at least there's a meaningful error now.
 
> 4. reboot the machine
> 
> 5. systemctl is-enabled lightdm.service
> enabled

# systemctl is-enabled lightdm
disabled
 
> Actual results:
> lightdm is not running
> systemctl enable/disable does not care of current and default target

Not anymore, as can be seen above.

> Expected results:
> lightdm is running

That can't be true, unless you first disable the original display-manager.service (gdm.service in this case), and then enable lightdm.
 
> systemctl enable/disable/is-enabled says if unit is really enabled for
> defined target.

It does now.

> It could show the name of the target for its really enabled.

Yes, that would be a nice improvement. I'll try to patch this upstream.

> Additional info:
> the reason is that all the time is my default target not graphical but some
> of the text one.
> Systemd scripts writes results for different settings, not current. There is
> no indication about that.

I can't parse this, sorry.


Because none of the original reporters haven't responded for a long time and I consider this bugzilla resolved, I'm closing the bug right now.

Comment 17 Karel Volný 2016-10-19 15:27:07 UTC
(In reply to Jan Synacek from comment #16)
> > 3. systemctl enable lightdm.service
> > ln -s '/usr/lib/systemd/system/lightdm.service'
> > '/etc/systemd/system/display-manager.service'
> 
> # systemctl enable lightdm
> Failed to execute operation: File exists
> 
> There could be an additional, more user-friendly message, but at least
> there's a meaningful error now.

ahem, with all the due respect, what may seem meaningful to you does not mean meaningful to all

which file exists? where in the whole systemctl manpage can I get some clue what this error means, what went wrong after executing a command that looks perfectly sane?

> > Expected results:
> > lightdm is running
> 
> That can't be true, unless you first disable the original
> display-manager.service (gdm.service in this case), and then enable lightdm.

well, I'm no expert in RHEL sofware groups, but I believe @base doesn't contain gdm (nor other graphical stuff), so following the original reproducer steps, this *can* be true

anyways, the situation should be handled somehow, because the intention of the user enabling lightdm is not to run gdm for sure, so it should get disabled automatically or at least a conflict reported

that's generic UI concept ... imagine you're listening to radio A and want to switch to station B ... so you push a button and nothing happens ... so you refer to user manual, find nothing, then search the Internet and find that you have to push another button to untune A and only then it will switch to station B ... does that make sense? aren't you happier when the tuner just changes frequencies without you having to tell that you really don't want to listen to A anymore?
a system running RHEL is far more sophisticated than radio receiver, yet it cannot do this work for the user?

> > Additional info:
> > the reason is that all the time is my default target not graphical but some
> > of the text one.
> > Systemd scripts writes results for different settings, not current. There is
> > no indication about that.
> 
> I can't parse this, sorry.

there is the "needinfo" checkbox that you can use to ask the reporter to explain ... I know that Czech => English => Czech sometimes isn't that easy, but in this case I don't have any troubles understanding Petr's text; however, if this really is a problem for you, you could even have asked him to explain in Czech instead

> Because none of the original reporters haven't responded for a long time

how does this justify closing the bug?

the last comment was from lnykryn "We should ..." which incidates that the devel took the ball onto his side, are we expected to write "ping" here at least once a year?

> and I consider this bugzilla resolved, I'm closing the bug right now.

maybe I have missed something, but I do not see how the original problem is fixed?

after repeating the steps, ligthdm still is not running, is it?

all I see is the workaround in comment #12, but, aside from the counterintuitive behaviour, I do not see(*) any mention in 'enable' description in systemctl manpage about the fact that after enabling a service that is supposed to just run (not depending on "when a particular kind of hardware is plugged in" e.g.) it would not run

(*) looking at systemd-231-10.fc25.x86_64

Comment 18 Jan Synacek 2016-10-20 07:03:58 UTC
Karel, stop arguing like a small child and take this to more technical level. Thank you. The very fact that you have reacted to this bugzilla after three years, and in the very same childish manner, speaks for itself.

I'm going to respond only to relevant things that you wrote.

> ahem, with all the due respect, what may seem meaningful to you does not mean meaningful to all

It says "File exists". In the systemctl manpage, you can read that the enable command creates symlinks. It may have some connection... Plus, we (and relevant parts of QA) know that the error messages are not user friendly, because they show string representation of glibc errnos. We can't do much about this right now.

> how does this justify closing the bug?

It wasn't the real justification for closing the bug and you know it. It's just you nitpicking.

> after repeating the steps, ligthdm still is not running, is it?

I'm going to repeat what I have already written, just for you:

"""
Expected results:
lightdm is running

That can't be true, unless you first disable the original display-manager.service (gdm.service in this case), and then enable lightdm.
"""

Understand know?

If not, reread comment #16 again, after a good cup of coffee and calming yourself first. Thank you.


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