Bug 627277

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.)

By "valid" I mean "designed to be used that way"; a.k.a "not silly".

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.

(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.)

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".

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?)

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.

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.

(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.

(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

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Ping what's the current status on this. 

Are we considering adding something like systemctl set default foo.target?

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.

(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.

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?

(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.

Committed upstream in http://cgit.freedesktop.org/systemd/systemd/commit/?id=99504dd4c.

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?

We assign blindly.

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. ).