cussing systemd - any way to get rid of it?

[DBelton]

I have run into one of my first major reasons not to upgrade to F15 if I can't find a solution to this problem. Hope some of you out there have a solution.

with systemd, is there any way to have services start in multi-user (old runlevel 3) but NOT start in graphical (old runlevel 5)?

It seems that everything that you set up to start in multi-user (runlevel 3) gets started when you start in graphical (runlevel 5)

with upstart (or sysvinit) You could set up a service to run only in runlevel 3, or you could put in both places and have it start up in runlevel 3 and runlevel 5.

[vallimar]

There may be some oblique shoddily documented method to do so, but I wouldn't know it.
From what I understood before, they are essentially the same, just that the graphical targets
also starts up X instead of dropping you to a terminal, which may or may not behave as expected.

They decided that runlevels were too antiquated and so removed them from consideration.

You can install upstart and initscripts-legacy, but it's really kind of a hacky method. You also
need to specify init=/sbin/upstart on the boot cmdline.

I rebuilt the initscripts and upstart packages for myself today to dump most of the systemd
bits to see if that improves it further. Cannot test until later when I am at that machine though.

[DBelton]

It's looking like I may have to go that route on my system. I have several services that I only want to start in runlevel 3. I don't want them running in a graphical boot.

I can tell already that systemd is going to go over like a lead balloon with linux server administrators.

[smr54]

I really wonder about this, as I don't know if it's just me, or admins in general.

For several years, RH was pretty much in the position of Windows, the only Linux server distribution around. Yes, there was Slack and Debian, but Debian was too anti-commercial, and often, the buying, and even implementation decisions, are made by those who figure, well, they have commercial support, blah blah.

Now, Ubuntu is starting a server install, which is a bit more like a server than a typical RH, with its attachment to Gnome--for example, if you want X on RHEL, and don't want 3rd party software, you have KDE, Gnome, or twm. Scientific Linux is offering matchbox, but I think that's SL only. (Though I'm not sure.)

SuSE has its version, don't know though what's going on with Novell, MS and all that. Oracle is probably the biggest threat, as they seem to be one of the truly evil companies, and have so much money that their executives' *rejected* mistresses can afford Times Square billboard ads to tell how evil the rejecting executive is. At present, Oracle is pretty much following RH, but one wonders, if RH goes more Windows-y with all this Fedora stuff aimed at the new user, if there is a market for sysadmins who will say, If I wanted Windows, we'd have gotten Windows, and start looking for other systems.

FreeBSD seems to have greatly improved binary upgrading, and that might start getting more of a corporate footing as well. I really don't know. I know, from forums, mailling lists, and personal friends, that a lot of sysadmin types don't like the GUI-ness of RH, as well as its bloat, but have no idea if this will have gradual, eventual impact, for example, Oracle saying, let's redo RH without all the GUI-ness, and start offering something that kept the good and got rid of what many sysadmins feel is bad.

If it happens, it won't be soon. RHEL6 hasn't gone over the edge, despite killing text mode installation, and businesses have a great deal of inertia, but one does wonder.

---------- Post added at 01:53 PM ---------- Previous post was at 11:55 AM ----------

Here's a cheat sheet for systemd.
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet

So far, it seems, like much of Fedora, overcomplicated and unnecessary.

[DBelton]

thanks for that link :)

I still don't see a way to load a service in the multi-user runlevel but not in the graphic runlevel, though :( It looks like the graphic runlevel runs everything in multi-user then runs graphic to add the graphic stuff.

[smr54]

Heh, here's another rant for ya then. It's actually from a FreeBSD user discussing usability. (One could add Arch, Slack, and possibly Debian to the list.)


BSD has always considered it more important to let the advanced user do more, than to let the novice do more. The theory, of course, is that novices become advanced users very quickly (a year or two), while advanced users use the system for a long time (decades). So there's probably less "fluffy" handholding frontends built into the system. On the other hand, addon packages carry their own. If KDE has some sort of user-help or tutorial or whatever built into it (I don't know, I don't use it), it'll have it on BSD too, since KDE is KDE wherever you use it. So it's rarely as much of an issue as it sounds.

Unfortunately, Fedora and many, probably most others, seem to be more into the fluff, rather than something useful to the more advanced user, be they sysadmin or not. And stuff gets into Gnome and KDE regardless, as mentioned in the quote. I frankly literally laughed out loud, as opposed to CQTM, chuckling quietly to myself, when I got a letter from a BSD using friend, complaining about what they termed useless piece of garbage, pulseaudio. (Hrrm, developed)by the same person doing systemd.) :D


Trollishly yours,

[dd_wizard]

Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.
The keword here is usually. That makes me think there's a way to do what you want to do. Maybe you should try posting on the dev mailing list, or file a bug?

dd_wizard

[marko]

Doesn't the stuff covered here imply that systemd does have ways to modify default run levels for services?

http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions

[jpollard]

Systemd appears to be trying to get rid of runlevels entirely.

You should be able to get the sysV init by adding "init=/sbin/init" or "init=/sbin/upstart" to the grub boot command line, but make sure you have upstart in /sbin.

I think (don't know for a fact) F15 still includes upstart by default.

[jvillain]

Here is what you can do. First cd to /lib/systemd/system

now runlevel5.target is a symlink to graphical.target.

If you do a cat on the graphical target you will see in the unit section a line that says

After=multi-user.target

but it doesn't have to be that. You could set up a new target multi-user-light.target and have it start what ever you want. Then set the line After=multi-user-light.target.

Or you could change it to After=basic.target and then load up the directory graphical.target.wants with symlinks to the services you do want to start.

systemd is very flexable and will let you do way more than init ever would. But that is a blessing and a curse.

[DBelton]

ok I filed a bug and got a response. Not the greatest solution in the world, but it seems like it would work

create a new .target that pulls in the multi-user.target
add the services I want to be unique to multi-user in the new target
then start that target instead of the multi-user.target when I wish to be in multi-user (non-graphical) mode

That way, I could keep the services I want to start in both runlevels in multi-user.target, the extra graphical services in graphical.target and the services I only want run in multi-user (non-graphical) in new.target.

Now all I need to figure out is how to control the actual order of loading those services...

(This is a really &^$&^ed up way of getting a system started, but I guess it works.)

comes out very very close to what jvillain suggested above.. :)

[jvillain]

Now all I need to figure out is how to control the actual order of loading those services...

And this is where we get more good and bad. You have to ask your self which services actually have to load in any particular order. The network needs to be running before NFS is going to work for you for example. But your web server and mail server can be starting up at the same time and don't need to be scheduled. Also we are atleast part way down the road but one of the things that systemd is supposed to handle is if your service has a dependency that isn't running already it will start the dependency for you. That requires all applications to be able to talk on the dbus to see who is running and I am sure not every one has rewritten their code to do that. If a service falls over it can automatically be restarted if wanted as well but I haven't figured out how to do that yet.

Here is some more documentation for you to look at. In particular you will probably find the first one interesting as it should help you start thinking about new ways to start looking at starting services. I'm not saying you will like it, just that there are options.

One last thing. If some thing isn't listed in a new fangled systemd service or target or what ever systemd will still look in the fsab, init.d directory etc for config information as a fall back.


http://0pointer.de/public/systemd-man/daemon.html

http://0pointer.de/blog/projects/systemd-for-admins-1.html
http://0pointer.de/blog/projects/systemd-for-admins-2.html
http://0pointer.de/blog/projects/systemd-for-admins-3.html
http://0pointer.de/blog/projects/systemd-for-admins-4.html

And you will want to read through each of these as well. (I know, I know)

http://0pointer.de/public/systemd-man/

[vallimar]

This does not seem like a better system at all. All that to do what took 2 quick commands
before? Thus far, I've only seen "way more complex (and broken)", not "way more". Having
to do triple (or more) the amount of work to achieve the same effect as before is not what
I would call flexibility. They also have yet to live up to their promises. Where are all
the on-demand bits we were promised from the get-go.. non-existant. They are already on
version 20 and its in a constant state of broken in some manner or another. SysVinit was
solid for years.. even upstart was pretty solid from the beginning, and you could actually
drop it in and run with it.. systemd.. not so much. You practically have to be one of the
developers to even know how to operate the thing. /endrant

[DBelton]

interesting. It looks like systemd will build the *.mount and *.automount for you from /etc/fstab if you add it to your fstab options. (comment=systemd.mount or comment=systemd.automount)

Edit:

your rant has a lot of very valid points, vallimar. I am trying to get into systemd and understand it, but the more I get into it, the more I see it is a PITA to use. Rather than typing 6-10 characters to add a service, now it takes 10 times that :dis:

[nimnull22]

I do not understand you.
Linux is just a "construction set" you can choose what to do by your self. If you want to have new kernel from F15 on F14 get a better repo. mirror of F15 and upgrade like yum upgrade kernel*, if you wish to add xorg and mesa - yum upgrade xorg, and so on. If you do not like systemd add init=/sbin/upstart to boot line. That is all. I think it is not necessary to upgrade all: kernel X11 and may be some applications, everything else can be from F14 - it will perfectly work.

This is what I learned so far.

[DBelton]

since it is a construction set and you can choose what to do, then see about choosing to put a taskbar in gnome shell. or see about choosing to drop a file on your desktop in gnome shell.

I don't think that is a choice.

But, I know what you are saying. and right now, I choose to check out systemd and at least give it a try before dumping the entire piece of #$% in the trash can.

[jvillain]

You have a choice right now. Will you have a choice in F16 or 17?

[nimnull22]

The right question is - do you need a choice?

Developers will always experiment with different software, hardware engineers will always give us new and weird devices. It does not mean that one have to follow, have to spend the time to understand the ideas (if there is any) and configure to make work comfortable.
Anyone how have chosen opensource OS like Linux or FreeBSD chose not just opensource software, but system configuration freedom. It is not like windowz where one have to by as is.
Here one can gather what is exactly necessary to be enough. And I really hope that Fedora will never enforce people to use only certain thing. That is why I like Linux and FreeBSD, and if later linux will become another windowz clone I will say it goodbye.

It was only my opinion.

[smr54]

Nope, not true. If my job requires RH, I can't choose FreeBSD or Debian. That's only valid for hobbyists, who can choose whatever they want.

If we're running an Oracle database, and it only lists RH, OEL and SuSE as supported platforms, I can't use FreeBSD.

While I understand your statement, in many cases, a person's job dictates their choice. Fedora, and other distributions will
usually aim their defaults towards a particular target, and while it may not prohibit one from using something else, it becomes a matter of
rather than working with the system, working around it (depending upon your personal needs and wants.)

So, in many ways, one can be as locked into a particular distribution, and said distribution's way of doing things, as one is
in proprietary systems.

For someone just using Linux on their own at home, however, your statement holds--though I would disagree with part of it, I *do* feel that Fedora, if not locking you into something, makes it so hard to avoid it, that you
wind up using something else.

[nimnull22]

On my job I do not have the internet - it is the rule.
Oracle is commercial application = windowz - they are making their business with RH. They are making money. They have to pay salaries, it is understandable.

I am talking about OS at home, where one wants to see things exactly he likes.

But problem with systemd is not the systemd it self - there is no normal documentation or GUI.
It makes people think that systemd is evil and has to be replaced.

[Dan]

... It is makes people think that systemd is evil and has to be replaced. Most petty dictatorships are like that. <..:p..>

(Just kidding here. I don't know enough about systemd to truly hate it ... yet.)

[smr54]

As nimnull says, at present, there is not enough documentation--for example, I looked at an old document which indicated chkconfig should work as it always has, but apparently that isn't the case.

Like Dan, I don't know enough about it yet, but it seems as if it's just going to be one more thing to have to work around, and something that really isn't going to fix any major problems.

[nimnull22]

For anyone who wants to understand how systemd works, there is two places:
/etc/systemd
/lib/systemd

Unfortunately I have to warn, that it is what I think and might be wrong way to make the acquaintance of systemd.

[RahulSundaram]

As nimnull says, at present, there is not enough documentation--for example, I looked at an old document which indicated chkconfig should work as it always has, but apparently that isn't the case.


It is certainly the case. If you are referring to

https://fedoraproject.org/wiki/Systemd#Does_chkconfig_command_work_with_systemd.3 F

Notice, how we are talking about using chkconfig to turn off/on services. chkconfig --list doesn't list all systemd services and it is noted within the command output itself. systemd comes with extensive documentation and we cover a lot more in the wiki as well. If you find anything missing, let me know or help out by editing the wiki. I wish even 1% of the people would take the time to do that.

[smr54]

That explains it, thank you. (I was confused by the testing list thread yesterday, where that page seemed to be incorrect).

[DBelton]

whaaaaa??? you mean someone on here actually read the wiki of the docs? **GASP** You are NOT a true linux user! LOL

Or did you completely screw it up first, then read the docs? (IF so, you are a linux user and I retract my statement above) :D

[jpollard]

whaaaaa??? you mean someone on here actually read the wiki of the docs? **GASP** You are NOT a true linux user! LOL

Or did you completely screw it up first, then read the docs? (IF so, you are a linux user and I retract my statement above) :D

There are SOME people that read available documentation first.

For me, it gives me information on whether I want to even give it a shot first.

I've worked with such networks before, and they are not pretty. My objections are much the same as others - complex, not easily modified, not easily controlled. We (there were several of us working on construction PERT charts) would always have to graph the network, add our modifications, run an analysis program on the data, then do it again. It usually took 2/3 cycles to add one node or a simple linear chain. And we didn't have to deal with timeouts, optional subnets, or failures (not for the analysis anyway, failures in operation caused scheduling changes, which called for reanalysis - and possible changes to the net...)

They aren't easy, or simple.

[DBelton]

:) yes, I know there are some that do read through the documentation (I happen to be one of them as well, probably one one the few that can actually follow IBM internal system documentation and will sit and read one in my spare time (I know, I must be into S&M :p ))

But for the most part, documentation may get used only after there is a problem

Now back to systemd.

My findings after playing around with it some are that it is overly complicated (at least on the user and configuration side, which is what most people will see).

It also depends on cgroups, which makes me wonder about one machine I have here that has always given me some problems with cgroups and I have had to turn them off on that box. Everything else will work around not having cgroups, but I am having doubts that systemd will since it is so heavily dependant upon using them.

I realize that some of the issues with systemd will be corrected when it no longer has to do a lot of extra things just to keep the sysV/upstart compatibility.

I can tell now that someone had better come up with a front-end (that works) to easily start and stop services in systemd very fast or else everybody will throw it out and go back to using upstart. Not many people are going to put up with having to type 80-100 characters to start a service that has a 5-6 character name. (I mean a front-end where you are back to having to enter just the 5-6 character service name and what levels you want it started in) just a script that would take input like "addservice servicename graphical" and the script adds all the other crap and builds the link for you would suffice for now. (this one issue will be the cause of numerous people running away from systemd by the thousands, or totally hosing their system due to a simple typo in the way too long command to add a service)

I'm sure there are many other items I will find as I progress (or degress) into the murky depths of systemd, but for now it looks to me like it is like using an entire roll of gauze when a small band-aid would suffice.

[RahulSundaram]

Hi

Two things:

1) systemd uses cgroups if it is available but will still work even if it is not available albeit some commands such as kill which depends on it won't work. So no problem there

2) service and chkconfig still works and you can continue using them if you want to for starting or stopping services or turning them on/off. So no problem here either. systemctl does offer more powerful options that are not available in any other init system but they are optional.

[DBelton]

Hi

Two things:

1) systemd uses cgroups if it is available but will still work even if it is not available albeit some commands such as kill which depends on it won't work. So no problem there

2) service and chkconfig still works and you can continue using them if you want to for starting or stopping services or turning them on/off. So no problem here either. systemctl does offer more powerful options that are not available in any other init system but they are optional.


Thanks for the heads up on the cgroups. I was worried that systemd would die a horrible death if cgroups weren't available since it seems to depend so heavily upon them.

and yes, I realize that chkconfig does still work to stop/start services, but I am one that likes to use the proper tool for the job :) so if I am digging into and learning about systemd, I will try and use the tools for systemd. (for one, there is no telling how long chkconfig will even be available once the full switch to systemd is done.) So far, systemctl seems to work as it is supposed to, my complaint is how much you have to type to start one service that only took a few keystrokes with chkconfig. Not a bug, but a design flaw.

I have also been trying out systemadm (the graphical interface for systemd) and haven't had much luck in using it. I can't get it to stop a service or even add a service. All it will do for me is to restart one. I'll try to get a little time this evening or tomorrow to dive a little deeper into that and see if I can get more information as to why it's not working for me.

Overall, I have found systemd to be running fairly stable, my biggest complaint is the wordiness of the commands. (I'm going to have to get me a new keyboard cause systemd is causing me to wear mine out. LOL)

[RahulSundaram]

Hi


chkconfig and service commands automatically call the systemctl equivalents when needed and hence both are "proper" tools. There is nothing whatsoever wrong with using them. Full switch to systemd is already done for all intend and purposes. chkconfig and service command will be available for the foreseeable future. it is not like it is high maintenance or anything.

systemctl start NetworkManager.service is not that different from service NetworkManager start and systemctl disable Networkmanager.service is not that different from chkconfig NetworkManager off and yes, it is a few keystrokes more but you are exaggerating about the impact especially since the older equivalent will continue to work fine.. systemd manages more than just services and hence the explicit names and this is by design so that the mapping is straight forward.

systemadm as noted in the wiki is work in progress and hence not installed by default. Don't use it unless you are a developer.

[DBelton]

it was installed by default on my system when I did a F15 install. I didn't even know what it was until after teh F15 install and it was there.

[RahulSundaram]

Hi

That is pretty unlikely since I don't see it specified in kickstart or comps as default. Run grep systemd-gtk in /var/log/yum.log and /root/anaconda-ks.cfg to figure out how it got installed. I definitely had to install it manually.

[DBelton]

it must have been during the install when I did the customize installation stuff, then.

It shows up in /var/log/yum.log but I know I didn't install it after the initial install. It was there on my first boot.

I guess I need to pay more attention to what I check when I customize my installation :D

Actually, I would have installed it even if I had known what it was, because the entire reason I installed F15 was to try out the new things and see where fedora is heading. This install will be completely wiped out and a fresh install done later when I get things all (or at least somewhat) figured out so I can change the things I want without having bad things laying around to mess things up.

There are a couple of things I'm going to be filing a bug report on as soon as I can pin down a little more information (like yum looping when I use --skip-broken) but overall, I haven't completely trashed my system yet, so that's a good sign for F15 :)

[vallimar]

I've been using systemd for awhile, and have put up with its bugginess for some time but
when your system gets hosed just trying to toggle a service, that's too much. Let me know
when that gets fixed and I'll consider switching back.

DBelton, if you haven't installed bash-completion yet, do so. Systemd comes with a completion
script so you can tab-complete most things to save on typing. Works for 'service' and many
other commands too. Why this isn't installed by default with bash is a mystery. You will want
to relog into any open console sessions, or manually source it. Keep in mind that if you make
later changes, it's designed so you cannot update it later without a relog once it's been loaded
into a terminal session.

Something I discovered digging around, if you do choose the upstart fallback method, but want
to keep the later chkconfig versions, you need to either use --no-redirect or set a ENV variable
SYSTEMCTL_SKIP_REDIRECT=1 to have it always on. This is so you can manipulate the init.d
service files instead of the systemd ones. When trying to enable/disable services, it does not
check if systemd is active, just blindly forwards to systemctl which fails if it isn't.

[RahulSundaram]

Hi
He has been suggested atleast two different ways of doing it and he has confirmed that one works and closed the bug report he filed. For those not following along, a quick rehash

graphical target is defined as multi-user target + X and if one wants to enable a service to start by default on the command line but not start it on the graphical target, the simplest way is to enable the service on multi-user target and just run

ln -s /dev/null /etc/systemd/system/graphical.target.wants/foo.service

This will ensure that the service won't start in the graphical target. You can also define a custom target that does what you want to do but that isn't necessary in this case.

[DBelton]

yes, you are correct, Rahul. There are several ways to accomplish what I was originally asking about, and the way you show above works rather nicely :)

I will admit that most of my problems with systemd, you cleared up for me. I had thought that it was installed by default on my machine and while I don't mind development code, I want it to be by my choice, and not something I thought was supposedly closer to being a finished product.

Once you showed me that I had installed it (during customizing my install) then quite a lot of things settled down in my old brain :)

I will say that systemd does do a pretty good job from what I have seen so far once you get used to the extra verbosity involved.

Most complaints will probably be that it does things different than SysV/upstart (that can be both good and bad) and takes a learning curve, but once you figure it out, it's not that hard. Some things are actually easier than with upstart.

Now.. Gnome 3 shell.. well.. that one is a totally different matter.. :D I'd love to plant a bomb under that code and blow it all to heck and back. LOL