|
when you update systemd, it serializes its execution state to disk and then reexecs itself with the new executable and loads its saved state
|
#
?
Nov 23, 2014 04:09
|
|
|
|
| # ? May 14, 2024 05:40 |
|
|
Avenging Dentist posted:lennart's bigass post (which i haven't read yet but thx for the link) probably answers my question, but i was mainly wondering about why it needed to be pid 1 in particular, since i would have naively assumed that putting everything in pid 1 would have problems (e.g. if systemd crashed or if you tried to update systemd, which i expect would happen a lot more often than a minimalist pid 1) because pid 1 has those rights and privileges and any init system needs those rights and privileges and systemd is an init system and therefore needs those rights and privileges and has to be pid 1 the fact that systemd is pid 1 makes no effective difference for anybody at all in any way that matters
|
|
#
?
Nov 23, 2014 04:19
|
|
|
seriously you're according 'pid 1' with some kind of weird totemic significance and it's kind of disturbing the forkdebian idiots do that when they start tossing out their disingenuous-as-poo poo tripe about the unix philosophy and whatever, I don't think they really believe it you shouldn't either
|
|
#
?
Nov 23, 2014 04:26
|
|
|
Progressive JPEG posted:its almost as if the people with any background on the matter already agree that systemd is good
|
|
#
?
Nov 23, 2014 04:43
|
|
|
|
|
#
?
Nov 23, 2014 04:48
|
|
|
yes which is why i was asking for a description by someone like that because i don't know poo poo about the linux kernel (although i'm at a loss as to why i want to change that)
|
|
#
?
Nov 23, 2014 05:38
|
|
|
Avenging Dentist posted:lennart's bigass post (which i haven't read yet but thx for the link) probably answers my question, but i was mainly wondering about why it needed to be pid 1 in particular, since i would have naively assumed that putting everything in pid 1 would have problems (e.g. if systemd crashed or if you tried to update systemd, which i expect would happen a lot more often than a minimalist pid 1) keep in mind that when you read anti-systemd diatribes a lot of them are just misinformed/lying (pick whatever explanation floats your boat) about systemd abusing pid 1 by putting twelve thousand kitchen sinks into it. systemd is composed of dozens of relatively small binaries and the pid #1 daemon is small because it implements just the stuff which actually needs to go into pid 1. systemd pid1 is more complicated than traditional sysvinit (because it does more) but we're not talking about cramming emacs in there either
|
|
#
?
Nov 23, 2014 06:23
|
|
|
BobHoward posted:keep in mind that when you read anti-systemd diatribes a lot of them are just misinformed/lying (pick whatever explanation floats your boat) about systemd abusing pid 1 by putting twelve thousand kitchen sinks into it right, i p much just assumed the anti-systemd people were wrong but i wanted to know more about the reasoning behind its design, if only because it might give me some ideas for how to write better posix-y code that doesn't assume the platform it was running on was built in the 70s
|
|
#
?
Nov 23, 2014 06:26
|
|
|
pseudorandom name posted:There's also the fiddly little things (set the hostname, set the locale, load the keyboard map, set the machine UUID, etc.) that init takes care of after the initramfs mounts the root file system and starts init and before init can start the system proper. launchd demonstrated well that pid 1 doesn't need to be the thing to do these for example, having pid 1 have anything to do with locale is just silly, that should be per-user host config, logging, etc. don't belong in pid 1 either. those are the kinds of things best run via independent services that should be started on-demand basically, the people saying systemd is bloated with unneeded stuff are right (edit: thanks to the above, I gather they're not, because systemd isn't doing most of it in pid 1), but they act like the solution is to go back to shell scripts which is totally hosed I mean, I've used systems where /etc/rc managed startup, init.d and run levels are a minor improvement on that, but they're still archaic garbage compared to modern systems like launchd eschaton fucked around with this message at 10:18 on Nov 23, 2014 |
|
#
?
Nov 23, 2014 10:15
|
|
|
i like the concept of /etc/rc. init.d is already too complicated
|
|
#
?
Nov 23, 2014 12:06
|
|
|
Avenging Dentist posted:right, i p much just assumed the anti-systemd people were wrong but i wanted to know more about the reasoning behind its design, if only because it might give me some ideas for how to write better posix-y code that doesn't assume the platform it was running on was built in the 70s You know when a neophyte dev gets all pissy at having to stick to the house style and goes of and writes a poo poo-ton of code that doesn't work with anything else? That's systemd, only Poettering is old enough to know better. If you want to write ultra-modern Linux code, just pretend it's Java and shunt everything over DBus.
|
|
#
?
Nov 23, 2014 12:38
|
|
|
i like declarative nonturingcomplete service config. it helps that its readable and short never had to cj lunix tho
|
|
#
?
Nov 23, 2014 12:38
|
|
|
I've cjed lots of linux, I've written software to CJ linux for my employer. I've never had to modify an init script for work.
|
|
#
?
Nov 23, 2014 12:42
|
|
|
Back to desktop world. Do you have your xterms set up to use orang on black or green on black. I prefer orance as the 286 I had in 1997 had an orange monochrome text display.
|
|
#
?
Nov 23, 2014 14:33
|
|
|
Zombywuf posted:You know when a neophyte dev gets all pissy at having to stick to the house style and goes of and writes a poo poo-ton of code that doesn't work with anything else? That's systemd, only Poettering is old enough to know better. lol If you want something thats 100% pure UNIX (not even then) use a BSD. Linux never was a UNIX. It's broadly compatible, but gently caress it's even a part of the Gnu's Not UNIX system. SystemD just makes this explicit: what happens if we move on from the state of the art in 1985? That includes a decent IPC system (DBus, i guess) and standardizing poo poo like process startup. Shell scripts are garbage for idiots. Yes i want race conditions on loving system startup---you, all idiot sysadmins #2 systemd is the first step to making sysadmins obsolete: if it's trivially easy to configure a service what do I need a reactionary rear end in a top hat for??? i want a fully integrated version of vagrant/chef/ansible + Nix/Guix where i can simply declaratively specify an environment and have it deploy across thousands+ instances. windows of all things is further along here, what with Azure and PS-DSC and such
|
|
#
?
Nov 23, 2014 14:54
|
|
|
Malcolm XML posted:#2 systemd is the first step to making sysadmins obsolete: if it's trivially easy to configure a service what do I need a reactionary rear end in a top hat for??? 
|
|
#
?
Nov 23, 2014 14:59
|
|
|
Malcolm XML posted:#2 systemd is the first step to making sysadmins obsolete: if it's trivially easy to configure a service what do I need a reactionary rear end in a top hat for??? config management is making sysadmin into a burger flipper type job. as an industry, we are telling it people: code or perish Malcolm XML posted:windows of all things is further along here, what with Azure and PS-DSC and such DSC is a good idea but it is useless right now. It is not even half-baked. They are clearly going the right direction but the end is not even on the horizon
|
|
#
?
Nov 23, 2014 16:13
|
|
|
eschaton posted:for example, having pid 1 have anything to do with locale is just silly, that should be per-user Just picking this as an example. The user locale is per user. The question is the locale for system services. Sysvinit has every single init script set it themselves. Most distros have settled on requiring all init scripts to source another one that sources another one to set it before they do anything. Systemd has two points of interest: the first is a separate binary and dbus service for the sysadmin to get/set the system locale. The second is during first boot, where it actually gets set "omg in pid 1". Its 48 lines of code. Opens /etc/locale.conf and sets environment variables. And of course, if services want to set it themselves they still can. This design seems sound. I don't know why the dbus service is necessary (paranoid forward compatibility perhaps), but it's existence should hardly be upsetting.
|
|
#
?
Nov 23, 2014 18:18
|
|
|
eschaton posted:launchd demonstrated well that pid 1 doesn't need to be the thing to do these And that's why they're systemd-localed, systemd-hostnamed, systemd-journald. They're not part of PID 1.
|
|
#
?
Nov 23, 2014 18:37
|
|
|
Notorious b.s.d. posted:config management is making sysadmin into a burger flipper type job. as an industry, we are telling it people: code or perish If you're curious, this was one of the better decisions I've seen made by Red Hat management. Red Hat is trying to lower the cost of a Linux sysadmin by making simple sysadmin tasks point-and-click like Microsoft or VMWare. This was the original goal of Cockpit before it got transformed into "manage your docker containers!!!"
|
|
#
?
Nov 23, 2014 18:50
|
|
|
Suspicious Dish posted:If you're curious, this was one of the better decisions I've seen made by Red Hat management. Red Hat is trying to lower the cost of a Linux sysadmin by making simple sysadmin tasks point-and-click like Microsoft or VMWare. This was the original goal of Cockpit before it got transformed into "manage your docker containers!!!" sysadmins are vestigial, much like "operators" and other such useless professions they are basically there to a) absorb useless loving arcana b) get in ur way death to sysadmins
|
|
#
?
Nov 23, 2014 18:51
|
|
|
crazypenguin posted:Just picking this as an example. and the answer is "US English"
|
|
#
?
Nov 23, 2014 18:53
|
|
|
what's docker useful for anyway
|
|
#
?
Nov 23, 2014 18:54
|
|
|
Avenging Dentist posted:right, i p much just assumed the anti-systemd people were wrong but i wanted to know more about the reasoning behind its design, if only because it might give me some ideas for how to write better posix-y code that doesn't assume the platform it was running on was built in the 70s the majority of anti-systemd people have decided they hate systemd because of its feng-shui or whatever and then retroactively invent bullshit technical justifications for their objections. they scream and shout that it's opaque and inherently buggy and difficult to fix and then, when pressed, point to a handful of really old bug reports and personal anecdotes like "well, i installed the bleeding edge version of my distro's first attempts to integrate systemd and didn't read the loving manual and i've sperglorded up the most hideously convoluted LVM partitioning setup on my special snowflake laptop and it didn't work SYSTEMD IS WRITTEN BY MICROSOFT FANBOY AMATEURS WHO DON'T UNDERSTAND UNIX" if you want to write a lazily activated service then yeah systemd has an API for this that you might want to make use of. posixy code has nothing to do with the service manager that starts up that code: from that perspective systemd locks your process in an inescapable cage with a sanitised environment (i.e. you don't inherit all the bullshit env vars if you are startup as a result of an admin typing /etc/init.d/buttservice start instead of your service being started from the system bootup rc script) but otherwise it leaves you to do your own thing. you need to be aware of systemd if you want to do the new things that systemd provides, it does not stop you from doing the things you could already do in the first place. as for systemd's design itself, the basic contrast is that systemd is declarative whereas sysvinit is imperative. systemd is told "bring the set of services currently running on the system to this state", reads the declarations that describe how the services installed on your system fit together, formulates a plan of action to bring the system from its current state into the state that you have requested, and then executes that plan. if a service is misbehaving, systemd's process grouping facilities have reliable ways of hunting down and killing every process within that service's process group. systemd can also act as a lazy-activating proxy for services that support it, massively speeding and parallelizing system bootup but also allowing systemd to understand the real dependencies between services instead of requiring these dependencies to be explained to it manually. this makes things a lot more robust and eliminates a lot of race conditions during system startup. sysvinit gives you distribution-specific stone knives in the form of the shell scripts in /etc/init.d (or /etc/rc.d/init.d). you can execute one of these shell scripts by hand to start or stop a service, or alternatively the bootup script /etc/rc.d/rc (or whatever it is) can fire off a sequence of these scripts one after the other to start up and shut down the entire system. if you want to do something different then you can hack on these shell scripts by hand and hopefully not gently caress anything up, only to have to do it again when the package manager wants to replace your site-local ball of configuration and commands with a new version. if it goes wrong, log in as root on a local single-user shell and try to figure it out. maybe something even got logged to some log file somewhere, maybe not. https://web.archive.org/web/20141020161905/http://forkfedora.org/ and that's just the absolute basic poo poo that systemd does.
|
|
#
?
Nov 23, 2014 18:56
|
|
|
Kiwi Ghost Chips posted:what's docker useful for anyway huh yeah What is it good for? Absolutely nothing, oh hoh, oh
|
|
#
?
Nov 23, 2014 18:59
|
|
|
z0rlandi viSSer posted:huh yeah much like computers in general
|
|
#
?
Nov 23, 2014 19:05
|
|
|
sounds like systemd is like maven where init is like ant/make. sounds like a good idea
|
|
#
?
Nov 23, 2014 19:08
|
|
|
Mr Dog posted:the majority of anti-systemd people have decided they hate systemd because of its feng-shui or whatever and then retroactively invent bullshit technical justifications for their objections. they scream and shout that it's opaque and inherently buggy and difficult to fix and then, when pressed, point to a handful of really old bug reports and personal anecdotes like "well, i installed the bleeding edge version of my distro's first attempts to integrate systemd and didn't read the loving manual and i've sperglorded up the most hideously convoluted LVM partitioning setup on my special snowflake laptop and it didn't work SYSTEMD IS WRITTEN BY MICROSOFT FANBOY AMATEURS WHO DON'T UNDERSTAND UNIX" the people hating on systemd are the "linux should be complicated because otherwise how can i lord over the APPLE USERS?????" also job security for admins who think the tribal knowledge of how to start nginx correctly should be valuable
|
|
#
?
Nov 23, 2014 19:11
|
|
|
nShaggar posted:sounds like systemd is like maven where init is like ant/make. sounds like a good idea kind of it has the declarative aspects but not as far as PS DSC does but it isn't windows where group policy being scriptable was at least thought about at some point, once now if u using windows servers it should be on azure, but that's slightly beside the point.
|
|
#
?
Nov 23, 2014 19:13
|
|
|
Kiwi Ghost Chips posted:what's docker useful for anyway if you're on linux it's a vm with less overhead if you're not on linux it's a vm with a docker-compatible API
|
|
#
?
Nov 23, 2014 20:00
|
|
|
|
|
#
?
Nov 23, 2014 20:20
|
|
|
Kiwi Ghost Chips posted:what's docker useful for anyway deploying applications
|
|
#
?
Nov 23, 2014 20:32
|
|
|
Docker is a really useful tool and is really cool but I'm mostly disappointed because Red Hat is fawning over it and chasing it. I mean, I totally understand. We were late to the cloud and are now pushing hard with that (CloudForms/ManageIQ, OpenShift, RDO/OpenStack contribution), and I have the feeling we sort of just want to be the first to ride a new and upcoming technology. But when some really neat projects with great goals are destroyed "because Docker!!!" it gets really frustrating.
|
|
#
?
Nov 23, 2014 20:40
|
|
|
I'm mostly bitter because I was in the middle of all the internal politics, when the project pivots were happening, when management just came in and stole a few of my coworkers and put them on Docker stuff. It's not anything against Docker, just RH's desire to win on a cloud tech.
|
|
#
?
Nov 23, 2014 20:41
|
|
|
coreos is better anyway. lol idk why redhat went with kubernetes
|
|
#
?
Nov 23, 2014 20:42
|
|
|
fleet is based on systemd. systemd is now integral to rhel. lets use kubernetes ftw -red hat corporate
|
|
#
?
Nov 23, 2014 20:42
|
|
|
Suspicious Dish posted:I'm mostly bitter because I was in the middle of all the internal politics, when the project pivots were happening, when management just came in and stole a few of my coworkers and put them on Docker stuff. It's not anything against Docker, just RH's desire to win on a cloud tech. cloud tech is what customers are asking for, the real problem is know-nothing CTOs
|
|
#
?
Nov 23, 2014 20:48
|
|
|
Mr Dog posted:the majority of anti-systemd people have decided they hate systemd because of its feng-shui or whatever and then retroactively invent bullshit technical justifications for their objections. honestly i think in most cases they hate it because lennart i know that's why i used to hate it, before i discovered i'd been using it for months and it was fine lennart did nothing wrong
|
|
#
?
Nov 23, 2014 20:57
|
|
|
we must secure the existence of our platform and a future for unix sysadmins
|
|
#
?
Nov 23, 2014 20:58
|
|
|
|
| # ? May 14, 2024 05:40 |
|
|
Lennart is the only one with the balls to actually do innovative and really cool things despite the poo poo he knows he'll get. There's so many things I'd love to do to unbreak basic poo poo but I can't because I know there will be boycotts.
|
|
#
?
Nov 23, 2014 21:00
|
|