Bug 627277 - RFE: systemctl command to change default target
RFE: systemctl command to change default target
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: systemd-RFE 959971
  Show dependency treegraph
 
Reported: 2010-08-25 10:29 EDT by Matthew Miller
Modified: 2013-09-13 07:43 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-13 07:43:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2010-08-25 10:29:00 EDT
Changing symlinks isn't hard, but it's a lot of typing and can look intimidating to new users. Plus, we can't do anything clever to check the validity of the target (only those that are valid for 'isolate' (or 'switch-to'!) are valid default targets, right?).

Therefore, a "setdefault" command for systemctl seems appropriate.
Comment 1 Bill Nottingham 2010-08-25 12:15:26 EDT
My understanding is that any target is 'valid' at a syntax level as a default target; it's just that many of them would be really dumb. (Sort of the equivalent of setting the default runlevel to 6 - it's valid, but silly.)
Comment 2 Matthew Miller 2010-08-25 12:22:58 EDT
By "valid" I mean "designed to be used that way"; a.k.a "not silly".
Comment 3 Bill Nottingham 2010-08-25 12:27:39 EDT
Right, but one idea with systemd is that the admin can set up their own custom targets. I'm not sure off the top of my head how you'd do this other than waking the entire dependency tree of the target heuristically, looking for certain items. It seems fragile in initial consideration.
Comment 4 Matthew Miller 2010-08-25 12:41:59 EDT
(In reply to comment #3)
> Right, but one idea with systemd is that the admin can set up their own custom
> targets. I'm not sure off the top of my head how you'd do this other than
> waking the entire dependency tree of the target heuristically, looking for
> certain items. It seems fragile in initial consideration.

On fedora-devel, we discussed a config option for a target which flags it as "not silly" to switch to as an isolated target. Since it's a) difficult to determine heuristically but b) incredibly important to know, having a flag in the file makes a lot of sense to me.

(There could be a flag to the command which says "accept possibly silly targets".)

I *think* Lennart has this on his todo list. (I can file a separate bug if that's helpful, so it doesn't get lost in everything else.)
Comment 5 Lennart Poettering 2010-08-25 13:23:26 EDT
I think for simplicity's sake we should encourage people to create symlinks in /etc/systemd/system as they wish. I don't think it is necessary to add high-level wrappers for all jobs you could ever want to do in /etc/systemd/system. People should not be afraid of creating the symlinks they wish on their own, and providing too many high-level wrappers might create the impression that you should never change any links manually in /etc/systemd/system, but actually that's what intend people to do. What makes sense to provide is an installation tool for "suggested" installations. But that we already have in "systemctl enable".
Comment 6 Matthew Miller 2010-08-25 13:30:48 EDT
For this one, I don't care for my own use. I'm concerned for documentation writers, support people, and intermediate users. I don't think that creating symlinks is simplicity for a lot of people. But if you want to mark this one as deferred I will not be offended.

(If someone wrote a patch adding this, would you take it?)
Comment 7 Rahul Sundaram 2010-08-25 13:32:11 EDT
Lennart, 

changing the runlevel or target is going to be a pretty common operation.  Having systemd do it directly seems eminently sensible to me.  Symlinks are nice and flexible but providing a systemd syntax for it is not a bad idea.  Having to remember paths for example is a pain compared to running a command if you are a sys admin.
Comment 8 Glen Turner 2011-06-07 00:29:55 EDT
Having just had to change the default run level in Fedora 15 it isn't a systemctl command I particularly need, but something in the man pages to say that altering the symlink is the expected means to achieve a change of default runlevel (as opposed to the symlink being something under the covers that if fiddled with will break systemd). Since there are only two runlevels of interest -- 3 and 5 -- it would seem fair to have examples in the man page.

  su
  umask 022
  cd /etc/systemd/system
  rm default.target
  ln -s /lib/systemd/system/runlevel3.target default.target

Also, it would be fair to sysadmins to point out in the man page that /etc/inittab has no effect on systemd. The comments in the inittab file dating from F14/upstart are quite misleading otherwise.
Comment 9 Michal Schmidt 2011-06-07 03:15:41 EDT
(In reply to comment #8)
>   su
>   umask 022
>   cd /etc/systemd/system
>   rm default.target
>   ln -s /lib/systemd/system/runlevel3.target default.target

You don't need to set umask. symlinks do not have permissions of their own. This should be enough:
su   # no need to mention that
ln -sf /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target

As for myself, I just put '3' or '5' in grub.conf.
Comment 10 Michal Schmidt 2011-06-07 03:17:13 EDT
(In reply to comment #8)
> The comments in the inittab file dating
> from F14/upstart are quite misleading otherwise.

My /etc/inittab says quite clearly:

# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
[...]
# To set a default target, run:
#
# ln -s /lib/systemd/system/<target name>.target /etc/systemd/system/default.target
Comment 11 Fedora Admin XMLRPC Client 2011-10-20 12:25:52 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Jóhann B. Guðmundsson 2012-02-27 05:55:02 EST
Ping what's the current status on this. 

Are we considering adding something like systemctl set default foo.target?
Comment 13 Braghadees 2012-03-04 06:16:31 EST
As a victim of the problem discussed by Mathew , I post this. I use fc15 kernel and recently came to know of systemd and curiously symlinked "/etc/systemd/system/default.target" to "/etc/systemd/system/rescue.target" 
       sudo ln -fs /etc/systemd/system/rescue.target
                      /etc/systemd/system/default.target
instead of "/lib/systemd/system/rescue.target". Now on booting the system stops with "Welcome to Fedora Lovelock 15!".Please help restore my system.
Comment 14 Michal Schmidt 2012-03-05 07:37:52 EST
(In reply to comment #13)
> Please help restore my system.

Boot with "systemd.unit=multi-user.target" command line parameter. Then remove the bad symlink.
Comment 15 Braghadees 2012-03-06 03:10:32 EST
I did boot under the multi-user.target config and edited the symlink forcibly using "ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target" successfully.
But upon booting with graphical.target , the systemd runs into a cyclic fault as like 

"systemd[]:graphical.target calls for a cyclic error"

Which is an approximation of error message i received at boot time(Sorry dont know to get the logging text as such).

And the graphical.target looks like this

[Unit]
Description=Graphical Interface
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
AllowIsolate=yes

[Install]
Alias=default.target

Is there anything wrong with this?
Comment 16 Michal Schmidt 2012-03-06 06:49:45 EST
(In reply to comment #15)
> I did boot under the multi-user.target config and edited the symlink forcibly
> using "ln -sf /lib/systemd/system/graphical.target
> /etc/systemd/system/default.target" successfully.

This symlink is OK.

> But upon booting with graphical.target , the systemd runs into a cyclic fault
> as like 
> 
> "systemd[]:graphical.target calls for a cyclic error"

Please file a new bug. Try to capture the error messages as exactly as possible.
Comment 17 Zbigniew Jędrzejewski-Szmek 2013-06-09 18:56:00 EDT
Committed upstream in http://cgit.freedesktop.org/systemd/systemd/commit/?id=99504dd4c.
Comment 18 Jóhann B. Guðmundsson 2013-06-10 09:33:10 EDT
Did we end up properly detecting if the target was "bootable" and or validate it's boot path and error out if that was not the case or do we just blindly assign default target to any target?
Comment 19 Zbigniew Jędrzejewski-Szmek 2013-06-10 10:24:59 EDT
We assign blindly.
Comment 20 Jóhann B. Guðmundsson 2013-06-10 10:50:41 EDT
The proper way to do this and implement this in the distribution is to detect if the boot target being set is actually bootable and error out properly before we implement this followed by a blog post in the systemd administration series from Lennart on how to create a minimal/local boot up target along with updates to our own distribution documentation.

I strongly suggest we do not implement this until we can and just have administrators jump through hoops to re-assign the default boot target and shoot themselves in the foot in the process if they do, if only just to prevent us winding up with plethora of bug/rfe reports from admins that create an custom target and decide then to make that the default target and start filing a report when it does not work as expected ( does not boot, did not pull in $FOO_unit does not shutdown, forgot to remove service/targets in the default.target.wants directory ( since this is assigned blindly I dont think it cleans out the current wants directory either ) etc. ).

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