23
24

Systemd for Upstart users (wiki.ubuntu.com)

men_cant_be_raped が 投稿

全 73 件のコメント
並べ替え:
ベスト
トップ新着論争中古い順Q&A

[–]bitwize 4ポイント5ポイント  (0子コメント)

Say what you will about systemd -- lord knows I have -- I'd take it in a heartbeat over Upstart.

[–]theportraitist 8ポイント9ポイント  (46子コメント)

I love systemd and systemctl. It really makes my life a lot easier thanks to how powerful the autocomplete is. Also we can't really stop Red Hat from using systemd. INIT is decades old and no longer takes care of our needs as elegantly as systemd does.

[–]teh_kankerer 0ポイント1ポイント  (45子コメント)

There are other things than sysvinit or systemd though.

I use runit which serves my needs very well and boots a lot more quickly because it's far smaller than systemd.

Turns out I never use stuff like socket activation, seats and all that stuff that systemd offers.

[–]natermer 5ポイント6ポイント  (32子コメント)

I am a heavy user of cgroups features for systemd and the '--user' per-user-session management of programs.

The '--user' is nice because it's replaced relying on shell scripts to launch stuff when I log in.

[–]whotookmynick 2ポイント3ポイント  (7子コメント)

without systemd you would not need systemd for cgroups

cgroups themselves are really simple

[–]OCCASIONAL_CATNAPPER 4ポイント5ポイント  (6子コメント)

Just be cautious, the long-term goal with the cgroup API is to redesign it so there's only a single hierarchy. Which is one of the reason systemd took to encapsulating it with dbus.

[–]whotookmynick 1ポイント2ポイント  (5子コメント)

systemd took to encapsulating it with dbus because systemd encapsulates everything as objects ("Units", in their terms)
not because of the cgroups API redesign

the redesign started to "simplify things"
i think the redesign is stupid, but hey whatever
one can read a biased explanation here
i'm sure there's a more objective one on LKML somewhere

cgroups interfaces are file or netlink and there are multiple daemons and libraries to control them
that one would "need systemd to use cgroups" is simply because systemd grabs cgroups for no good reason
without systemd one can use cgroups in any way one sees fit (usually with simpler interfaces)

edit: it's still good to read the kernel doc on cgroups, to understand their simplicity in design

[–]OCCASIONAL_CATNAPPER 0ポイント1ポイント  (4子コメント)

Well, I'm paraphrasing Lennart's explanation: https://lwn.net/Articles/555922/

I didn't really want to dive into the reasons because I can't say I have the experience with the API to think critically about it - they say its unnecessarily complicated and racy because of the multiple hierarchies. I can see how that be entirely plausible.

Anyways, I don't think what you're suggesting isn't a good or useful idea. I just wanted to put a disclaimer on it because I don't think you should treat the cgroup filesystem like a stable API just yet.

[–]whotookmynick 1ポイント2ポイント  (3子コメント)

i'm saying that there are other daemons that do that, not just systemd
and that when systemd grabs cgroups the other userspace implementations have to use the systemd interface
so on systems that don't use systemd one can use whatever (and on all systems, that "whatever" can abstract)

the Lennart post you posted says that using many different controllers at the same time can lead to race conditions when miss-used, not that cgroups are inherently racy

systemd uses cgroups to track processes, that it does not have to use at all
on systems without systemd one can use anything they want, including the kernel interface that is simple

i understand what you are saying but i am saying that the systemd provided dbus interface is not the only way to use cgroups and will never be the only way to use cgroups
the example of libcg (that Lennart is advising to switch to the systemd interface) will most probably work regardless of that change

cgroups are a kernel thing, that is what i'm saying
that one will need to use systemd to use cgroups on systems with systemd is the result of systemd using cgroups, not of anything else
systemd and logind could use proc events to do their tracking, but they are designed to use cgroups (that fit into what logind does but not entirely in what the process tracking part of systemd does)
edit: funny thing, i remember reading that they want to put every process into its own cgroup

Lennarts explanations are always from the POV of systemd, thus most of the time are tautological

[–]OCCASIONAL_CATNAPPER 1ポイント2ポイント  (2子コメント)

If you think we're having an argument here, I think you might be reading a bit too much into what I'm saying.

[–]whotookmynick 0ポイント1ポイント  (1子コメント)

my bad, i was talking about a completely different thing then you

i was replying to

I am a heavy user of cgroups features for systemd ...

with the fact that you don't need systemd to use cgroups
it is common for people to think that you do

[–]teh_kankerer 0ポイント1ポイント  (23子コメント)

Weirdly enough, I had to write my own program for "user sessions" because none, not even systemds usage thereof does what I needed. Which is weird, I couldn't find anything that does while it's such a common use case.

All I needed was to be able to run daemons that extend the duration of a "session" where multiple sessions of the same type can co-exist independently at the same time for the same user and thus need multiple instances of the same daemon started.

For instance, I run a daemon which manages certain functionality of displaying a new random inspirational quote on my wallpaper amongst other things. This daemon needs to start and end with the X session and if I run multiple X sessions at the same time obviously multiple ones need to be started and kept apart. For some reason systemd can't do this while it seems like a really common usecase so I had to write my own management thereof.

[–]natermer 3ポイント4ポイント  (11子コメント)

independently at the same time for the same user and thus need multiple instances of the same daemon started.

You can pass arguments to unit files to create multiple instances of the same daemon running.

Something like

systemctl --user start wallpaper@:1

But more then likely you will want to tie that into another unit file that is used to start your X session so that these things are tied together. Since user sessions are system-wide and not independent entities (example: your firefox's config dir is going to be shared between all firefox processes unless you take extra steps. All your applications are going to be like this.) it's a little bit non-standard, but it should be doable.

[–]teh_kankerer 0ポイント1ポイント  (10子コメント)

Well, that's the problem, what if I want multiple login sessions each having their own daemon? Say I use a daemon which regulates my prompt behaviour, say my prompt is so advanced it needs a permanent daemon to govern it. Each terminal shell would then need its own session. I no of no way to do that with systemd or anything and I asked around and it doesn't seem to exist. Which is really weird because it seems like a use case that's not esoteric at all.

[–]OCCASIONAL_CATNAPPER 3ポイント4ポイント  (9子コメント)

systemd-run --user <your daemon> and you can launch whatever command you want as either a systemd service or a scopep1 dynamically.

1 scope units only manage externally created processes, and do not fork off processes on its own. So you get a process wrapped in a cgroup but still attached to the tty, for example.

[–]teh_kankerer 0ポイント1ポイント  (8子コメント)

Yes, but that doesn't do what I want. That does not create a session that keeps multiple instances of the same daemon apart with a defined duration.

Like, how would that enable me to set up a system where a set of daemons would run for the duration of a bash shell, are tied to that specific shell and stop when the shell is closed all the while of course spawning a different one for each individual shell I open.

[–]OCCASIONAL_CATNAPPER 3ポイント4ポイント  (6子コメント)

There's a pam module that registers a new session when you login. If you want a session for every shell, you'll have to write that glue yourself. Its not something systemd provides...

That said, a user session, from the cgroup/systemd perspective, is just a slice. (eg user-1000.slice - your first login might falls under user-1000.slice/session-c1.scope).

The is no reason you couldn't write something to maintain, say, user-1000.slice/shell-435.scope (where 435 is meant to be a pid), and put your shell under that. For this, all you need is is to need integrate a light session manager into your shell to bootstrap setting up the scope. Now just launch your daemon - all forked processes from your shell will now also end up under this new shell scope. In fact, you can now kill everything started from that shell at once, if you like, including anything that attempted to double fork away. (Honestly, this sounds like an interesting weekend project - I've already done similar stuff with the dbus API, I might take a crack at it).

And that gets me to the last point: what you're asking for isn't in the scope of what systemd was designed to support. The cgroups API is certainly rich enough to support what you're asking for, but its not going to be supported by the core set of tools.

Look at other session managers for example: gnome-session, for example, can use take advantage of systemd. In which case gnome-session talks to systemd over dbus to launch the session daemons on demand. There is no special integration done from the systemd side of it, gnome-session is just taking advantage of the APIs to tell systemd what to do and when to do it.

[–]teh_kankerer 0ポイント1ポイント  (5子コメント)

And that gets me to the last point: what you're asking for isn't in the scope of what systemd was designed to support.

It isn't, that's why I'm not relying on systemd to do it for me. I'm just baffled by the fact that it seems to not exist, I asked around in many channels. It seems like a very obvious use case but a lot of people ask me "Why would you want that?"

I cannot possibly imagine that I'm the first one who needed this kind of functionality.

[–]danielkza 2ポイント3ポイント  (0子コメント)

I don't think systemd is the correct tool for the job you want. You have a task with a lifetime that should be bound by a running program. The natural fit is to have the task be a child of that program, and shells can manage those kinds of jobs natively.

[–]XANi_ 0ポイント1ポイント  (9子コメント)

Err, that usecase might not be as common as you think ;) Just "running multiple X sessions" would probably be less than 0.1% of users

[–]teh_kankerer 1ポイント2ポイント  (8子コメント)

If it was that uncommon they would not have by default typically set out f7-f12 out just for that.

I mean, dbus can spawn multiple session busses for exactly that reason.

[–]XANi_ 0ポイント1ポイント  (7子コメント)

I haven't seen any distro that by default runs multiple X servers on F7-12, which one you are using.

And it is on F7 because traditionally F1-6 were for text consoles so it was "first one free". F12 was sometimes used for permanent "system" log

[–]teh_kankerer 0ポイント1ポイント  (6子コメント)

I haven't seen any distro that by default runs multiple X servers on F7-12, which one you are using.

Pretty much every one does it, it puts them on F7-F12 when you start one. Some distros by default have a "display manager" or whatever it's called rigged to start an X server by default on bootup in which case it'll be on F7, but if you start another one it'll be on F8.

I always thought F1 to F6 are used for text consoles to keep F7-F12 for X servers.

[–]XANi_ 0ポイント1ポイント  (5子コメント)

Nope, X just picks up first free one, if you removed F2-6 it would start on F2.

And no, most people do not start a second X server ;p

[–]teh_kankerer 0ポイント1ポイント  (4子コメント)

Nope, X just picks up first free one, if you removed F2-6 it would start on F2.

I know that, I mean they by default do not start a GETTY on anything higher than 6 to leave room for 6 X servers.

And no, most people do not start a second X server ;p

Then how do they maintain two different login sessions when they say want to test something without screwing their main one up?

[–]theportraitist 4ポイント5ポイント  (11子コメント)

I see what you mean, but Red Hat is, like it or not, the 400 pound gorilla in the room. When RH took over CENTOS they pretty much have taken over the enterprise space.

[–]teh_kankerer -3ポイント-2ポイント  (10子コメント)

Meh, this whole "systemd has won" thing doesn't phase me, it's a different world than I live in.

systemd has only won in "just works" distros. Distros that attempt to give users more direct control over their system like Slackware, Gentoo, Void etc will continue to let users pick their own init system and make their packages agnostic of the init. / service manager. Gentoo supports systemd to the point of ebuilds shipping systemd service units. But few users use it. Gentoo is all about manual control and choice and in the end systemd as a monolithic program gets in your way for that.

systemd can continue to exist and do what it wants. In the end, it's almost like a Windows program, it doesn't actually affect me much. It's a completely different world.

[–]Floppie7th 5ポイント6ポイント  (4子コメント)

Personally, what I like about systemd is the ease of writing unit files. Any of my systems that require custom services get CentOS because systemd. Outside of that, it doesn't provide any advantages to me over e.g. runit, as you mentioned.

[–]teh_kankerer -2ポイント-1ポイント  (3子コメント)

systemd provides many advantages over runit, just like runit provides many advantages over systemd. But the ease of writing unit files isn't one of them. Runit service files are considerably easier than systemd units. Runit service files are basically nothing more than what you would put in the Exec= field of a systemd unit.

[–]Floppie7th 0ポイント1ポイント  (2子コメント)

It provides many advantages. It doesn't provide any advantages to me. That's why I explicitly included that language.

[–]teh_kankerer 1ポイント2ポイント  (1子コメント)

Oh, I read over the "to me" I guess.

But yes, it's all personal, that's why being able to mix and match and choose is important. If I had a need for cgroups systemd would be more attractive to me, currently runit fills all my needs except one for which I had to write my own functionality as it seems it doesn't actually exist.

[–]Floppie7th 0ポイント1ポイント  (0子コメント)

All my use cases for cgroups are just OS containers as a replacement for VMs, and I've got a Proxmox 3.4 cluster for that (which is still on an ancient kernel and sysvinit), so no need there.

[–]natermer 2ポイント3ポイント  (4子コメント)

systemd has only won in "just works" distros.

As opposed to 'does not actually work' or 'fancy yourself a OS developer?' distros. :P

[–]teh_kankerer 1ポイント2ポイント  (3子コメント)

No, as opposed to "works in the way you want it to" distros.

"Just works" is pretty useless if it doesn't work in the way you want it to. Yeah, fantastic, Debian gives you a fully functional GNOME 3 out of the box. But then you spend three times the time you would spend on Gentoo to make it work the way you want it to that you don't gain any time at all.

[–]natermer 4ポイント5ポイント  (2子コメント)

"Just works" is pretty useless if it doesn't work in the way you want it to.

What can you accomplish in Gentoo that you can't do in Debian or Arch?

And don't say 'Not run Systemd' or 'use deamontools instead'... because those are mechanisms to accomplish things, not goals. Not results.

Because, believe it or not, all Linux distros run all the same software. They use all the same source code, use all the same libraries, compiled in just about the same way, and use the same kernels. All of them are customizable. I don't need 'portage' to change how my Linux install works. If I want to use different compiler settings I build all my Deb packages or RPMs from source nearly as easily as I can do in Gentoo.

The purpose of a OS isn't to make you feel good about it's design. The purpose of a OS to make it easy to run applications, servers, and write software.

So what is the MASSIVE advantage to switching from a OS that takes 15 minutes to setup from scratch or just seconds if you have decent automation... to one that takes hours, or even day and you have to write all the automation yourself?

Why bring up 'runit' in article comments like this? What is the advantage? Why should anybody give a shit? Why not just comment on what is in the art article? Why try to derail the discussion with your own personal obsessions?

What is the point?

There is no point.

I am perfectly fine with people screwing around and having fun with OSes. Hobby OSes like KfreeBSD/Debian is great stuff.. and I know Gentoo is used for some embedded things. All that is fine and perfectly OK.

If you like runit then fine. Make a blog post about how awesome it is and subtmit it to r/linux.

[–]teh_kankerer 1ポイント2ポイント  (0子コメント)

What can you accomplish in Gentoo that you can't do in Debian or Arch?

Absolutely nothing, they are free software, thus they can be modified to whatever you want in theory, you can turn Debian into a racing game if you want.

The point is that Gentoo makes it easier and less time consuming than Arch or Debian to end up with the system you want. It's possible for all of them, but easier on Gentoo.

The purpose of a OS isn't to make you feel good about it's design. The purpose of a OS to make it easy to run applications, servers, and write software.

Quite right. And Gentoo makes it easier to run that software that I want. Not only that, it makes it easier to run it in a lower memory and CPU profile. Can you build everything from source on Debian to do that? Yes, but the toolset isn't there to automatically track conditional dependencies that Gentoo has, thus you have to manually administrate that stuff which is extremely time consuming compared to using the work Gentoo has already put into automating that.

So what is the MASSIVE advantage to switching from a OS that takes 15 minutes to setup from scratch or just seconds if you have decent automation... to one that takes hours, or even day and you have to write all the automation yourself?

Because like I said, it takes way longer on Debian to arrive at the system I have right now than on Gentoo and it is considerably more time consuming to maintain it.

I like to use the office chair analogy myself because it some-how fits:

  • Debian is an already built office chair, but it may not fit your back, it may not have the appropriate height, sure, it's an office chair with settings but that can only go so far.

  • Arch is an IKEA office chair, you put it together yourself, it comes with instructions, but ultimately you cna't go much further easily than deciding whether you want to leave out the wheels and armrests or not.

  • Gentoo is a set of deluxe power tools and infinite free raw materials to make the chair you want that fits your back perfectly, has everything you need, and as it has ntohing you don't need it's far lighter and easier to move around.

Now, of course you can just get your non power tools and take your Debian chair and make your perfect chair of it with nothing more than a primitive saw and a screw driver? But why would you? It's a lot easier to use the deluxe power tools that Gentoo offers which are advanced enough that they automatically measure stuff up for you and bolt it together at the press of a button. Portage is almost declarative, you specify the system you want in your world file, do a world update and a world clean afterwards and you have the specified system you desire.

Why bring up 'runit' in article comments like this? What is the advantage? Why should anybody give a shit? Why not just comment on what is in the art article? Why try to derail the discussion with your own personal obsessions?

Because someone said that systemd was better than sysvinit, as if sysvinit was the only alterative to systemd. I'm just pointing out more alternatives exist than sysvinit.

What is the point? There is no point.

Why do you ask if you already think you know the answer?

I am perfectly fine with people screwing around and having fun with OSes. Hobby OSes like KfreeBSD/Debian is great stuff.. and I know Gentoo is used for some embedded things. All that is fine and perfectly OK. If you like runit then fine. Make a blog post about how awesome it is and subtmit it to r/linux.

This has nothing to do with whether runit is good or not, it has to do with runit existing and that thus the argument in favour of systemd of "sysvinit is old and archaic and no longer fills modern needs" is flawed. It would only work if sysvinit and systemd were the only things existing, which isn't true.

[–]Kamiru_ 1ポイント2ポイント  (0子コメント)

And don't say 'Not run Systemd' or 'use deamontools instead'... because those are mechanisms to accomplish things, not goals. Not results.

That's like saying what can <insert program or distro here> do except <list of thing things my program/distro can't do> do?

Because, believe it or not, all Linux distros run all the same software. They use all the same source code, use all the same libraries, compiled in just about the same way, and use the same kernels.

That's pretty much the whole point, with a source distro you can actually use musl instead of glibc, or a different init/rc system. you can compile programs a different way, or use kernels with certain patches.

The purpose of a OS isn't to make you feel good about it's design. The purpose of a OS to make it easy to run applications, servers, and write software.

That's the point of why YOU run an OS, not why I or maybe other people use certain distro's. It's like saying "hurr why not just use osx, it also has a terminal, it just werks unlike linux".