Re: [gentoo-dev] pid 1 design
Luca Barbato wrote: Repeat after me: having your first process require anything more than libc is stupid and dangerous. Why do you say? And why is libc different from other libraries, say libuuid or libext2fs? I mean: Why allow pid 1 to require libc, it could just be statically linked. //Peter
Re: [gentoo-dev] pid 1 design
On Thu, Aug 9, 2012 at 10:02 AM, Peter Stuge pe...@stuge.se wrote: Luca Barbato wrote: Repeat after me: having your first process require anything more than libc is stupid and dangerous. Why do you say? And why is libc different from other libraries, say libuuid or libext2fs? I mean: Why allow pid 1 to require libc, it could just be statically linked. So, while I've had only positive (but limited) experiences with systemd, I can understand the fundamental design concern with having a complex process running as pid 1. If init dies, the kernel panics (just boot your system with init=/bin/bash and type exit to see). So, a simple init that is less likely to die is a good thing. That said, init NEEDS to be able to communicate with other processes if you don't want it to keep propping things up when you're trying to shut the system down. This is usually done via signals (init can trap them all at least on linux), but I believe there are other mechanisms that have been used in traditional init implementations. It seems like the big changes to systemd/etc are to allow it to communicate via dbus. I'm not sure why having systemd be a monolithic PID=1 solution was chosen - that is probably a better topic for their lists. Maybe a more resilient solution would be to have an init as PID=1 that does nothing but launch systemd and keep it propped up until it gets a signal from systemd. However, that could have issues I'm just not thinking of. That could be accomplished just by running the traditional init and having a runlevel with just systemd in it, aside from any issues not being PID 1 creates for systemd. Rich
Re: [gentoo-dev] pid 1 design
On 08/09/2012 04:02 PM, Peter Stuge wrote: Luca Barbato wrote: Repeat after me: having your first process require anything more than libc is stupid and dangerous. Why do you say? Because libc supposedly should be stable, other libraries are a bit more prone to radical changes and other annoyances. You wouldn't like to reboot your system if you replace/update dbus or glib, do you? And why is libc different from other libraries, say libuuid or libext2fs? I mean: Why allow pid 1 to require libc, it could just be statically linked. Actually statically linked initial process would be another reason why you'd like to NOT use large libraries and in large number. Obviously if you are thinking about desktop and not system in which replacing kernels should be done w/out downtime (qnx and some linux patches let you do that) it isn't a huge concern. Yet I'm not used to have to reboot after issuing emerge -u world and most of the times I don't have even to restart X... lu
Re: [gentoo-dev] pid 1 design
On Thu, Aug 9, 2012 at 11:25 AM, Rich Freeman ri...@gentoo.org wrote: ...have an init as PID=1 that does nothing but launch systemd and keep it propped up until it gets a signal from systemd. However, that could have issues I'm just not thinking of. I'm not the maintainer, but this method does seem to work pretty well for OpenRC and our old friend baselayout-1 (so, the last decade or so, as I understand it).
Re: [gentoo-dev] pid 1 design
On Thu, Aug 9, 2012 at 12:00 PM, Wyatt Epp wyatt@gmail.com wrote: On Thu, Aug 9, 2012 at 11:25 AM, Rich Freeman ri...@gentoo.org wrote: ...have an init as PID=1 that does nothing but launch systemd and keep it propped up until it gets a signal from systemd. However, that could have issues I'm just not thinking of. I'm not the maintainer, but this method does seem to work pretty well for OpenRC and our old friend baselayout-1 (so, the last decade or so, as I understand it). Yes, but OpenRC basically just launches processes and considers itself done with them. Systemd is a bit more like a shepherd, looking after things for their entire lifecycle. When you use openrc to stop a process it just runs a script which is responsible for cleaning up. If you stop a systemd service it can try nicely first, but if any descendant of the service is left running it will be cleaned up with a vengeance. If a process is supposed to be running and stops, systemd can restart it (which makes it more like init - which restarts anything in inittab if it dies). Systemd isn't a like-for-like replacement for traditional inits. It aims to be much more, so this is a bit of an apples-to-oranges comparison. Again, I'm not sure that it HAS to work the way it does, but I wouldn't dismiss their design simply because it is different. Also again, if curious I'd probably ask on their own list, assuming it hasn't already been answered there. Rich
Re: [gentoo-dev] pid 1 design
On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote: Yet I'm not used to have to reboot after issuing emerge -u world and most of the times I don't have even to restart X... What if sysvinit is updated as part of that emerge -u world? Don't you reboot then? William pgpysXEoQjlOV.pgp Description: PGP signature
Re: [gentoo-dev] pid 1 design
Ok folks, I hit the wrong key; this was meant to go to the list. On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote: Yet I'm not used to have to reboot after issuing emerge -u world and most of the times I don't have even to restart X... What if sysvinit is updated during that emerge -u world? Don't you reboot then? William pgpyqWwgIBf2C.pgp Description: PGP signature
Re: [gentoo-dev] pid 1 design
Rich Freeman wrote: Systemd is a bit more like a shepherd, looking after things for their entire lifecycle. This is a big part of why it is so useful. I threw out init scripts because it was retarded to not monitor long-running processes on servers. Those processes shouldn't fail, but sometimes they do anyway. sysvinit does the monitoring already and I wanted to write my own monitoring solution sometime in the 90s, until I found daemontools which did exactly what I wanted to do, and in a way quite similar to how I would have implemented it. Win. \o/ Systemd isn't a like-for-like replacement for traditional inits. It aims to be much more, so this is a bit of an apples-to-oranges comparison. Yes, it is much more, which is a very nice thing on the systems it supports. I believe systemd is not usuable at all outside Linux and will not likely ever be, so for prefix there will anyway always be systemd alternatives in Gentoo! And on those systems the service files should never be installed. Again, I'm not sure that it HAS to work the way it does I would say that it does, because it is required in order to accomplish what systemd wants to deliver. //Peter
Re: [gentoo-dev] pid 1 design
On Thu, 9 Aug 2012 22:27:37 +0200 Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: Systemd is a bit more like a shepherd, looking after things for their entire lifecycle. This is a big part of why it is so useful. I threw out init scripts because it was retarded to not monitor long-running processes on servers. Those processes shouldn't fail, but sometimes they do anyway. sysvinit does the monitoring already and I wanted to write my own monitoring solution sometime in the 90s, until I found daemontools which did exactly what I wanted to do, and in a way quite similar to how I would have implemented it. Win. \o/ I still remember using djbdns for a while. I especially threw away the daemontools part of it and wrote openrc scripts to not have 20 additional processes to run a tiny DNS server. Systemd isn't a like-for-like replacement for traditional inits. It aims to be much more, so this is a bit of an apples-to-oranges comparison. Yes, it is much more, which is a very nice thing on the systems it supports. I believe systemd is not usuable at all outside Linux and will not likely ever be, so for prefix there will anyway always be systemd alternatives in Gentoo! And on those systems the service files should never be installed. Considering that systemd unit files are sometimes shipped with upstream packages, and often they are practically equivalent to openrc init scripts, I'd rather see openrc supporting that file format as an extension and using it instead of duplicating the same thing in init.d scripts. And yes, that means that people masking service files shoot themselves in the foot. Also, if I had more time (or support), I'd probably start working on a systemd-compatible init system with a more portable design. Again, I'm not sure that it HAS to work the way it does I would say that it does, because it is required in order to accomplish what systemd wants to deliver. Not necessarily. You can move many 'extra' systemd features outside of PID 1. For example, unit dependency trees are complex by definition and practically not necessary for PID 1. In other words, it could be designed to move more complex (and thus risky) tasks outside of PID 1. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] pid 1 design
On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny mgo...@gentoo.org wrote: On Thu, 9 Aug 2012 22:27:37 +0200 Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: [snip] Systemd isn't a like-for-like replacement for traditional inits. It aims to be much more, so this is a bit of an apples-to-oranges comparison. Yes, it is much more, which is a very nice thing on the systems it supports. I believe systemd is not usuable at all outside Linux and will not likely ever be, so for prefix there will anyway always be systemd alternatives in Gentoo! And on those systems the service files should never be installed. Considering that systemd unit files are sometimes shipped with upstream packages, and often they are practically equivalent to openrc init scripts, I'd rather see openrc supporting that file format as an extension and using it instead of duplicating the same thing in init.d scripts. And yes, that means that people masking service files shoot themselves in the foot. Also, if I had more time (or support), I'd probably start working on a systemd-compatible init system with a more portable design. I would find this very interesting. I doubt I could find time for much active contribution, unfortunately, but I'd help where I could. Again, I'm not sure that it HAS to work the way it does I would say that it does, because it is required in order to accomplish what systemd wants to deliver. Not necessarily. You can move many 'extra' systemd features outside of PID 1. For example, unit dependency trees are complex by definition and practically not necessary for PID 1. In other words, it could be designed to move more complex (and thus risky) tasks outside of PID 1. +1 -- :wq
Re: [gentoo-dev] pid 1 design
On Thu, 9 Aug 2012 12:30:54 -0500 William Hubbs willi...@gentoo.org wrote: Ok folks, I hit the wrong key; this was meant to go to the list. On Thu, Aug 09, 2012 at 05:59:39PM +0200, Luca Barbato wrote: Yet I'm not used to have to reboot after issuing emerge -u world and most of the times I don't have even to restart X... What if sysvinit is updated during that emerge -u world? Don't you reboot then? William # telinit U (also works for libc replacement, and it’s actually done automatically by the sysvinit ebuild) Chris
Re: [gentoo-dev] pid 1 design
On Thu, 9 Aug 2012 16:45:28 -0400 Michael Mol mike...@gmail.com wrote: On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny mgo...@gentoo.org wrote: On Thu, 9 Aug 2012 22:27:37 +0200 Peter Stuge pe...@stuge.se wrote: Rich Freeman wrote: [snip] Systemd isn't a like-for-like replacement for traditional inits. It aims to be much more, so this is a bit of an apples-to-oranges comparison. Yes, it is much more, which is a very nice thing on the systems it supports. I believe systemd is not usuable at all outside Linux and will not likely ever be, so for prefix there will anyway always be systemd alternatives in Gentoo! And on those systems the service files should never be installed. Considering that systemd unit files are sometimes shipped with upstream packages, and often they are practically equivalent to openrc init scripts, I'd rather see openrc supporting that file format as an extension and using it instead of duplicating the same thing in init.d scripts. And yes, that means that people masking service files shoot themselves in the foot. Also, if I had more time (or support), I'd probably start working on a systemd-compatible init system with a more portable design. I would find this very interesting. I doubt I could find time for much active contribution, unfortunately, but I'd help where I could. Well, the sad thing is that I don't really have much expertise in this area. I like the philosophy of designing many smalls things which just work well together, so I would probably start that by reinventing some helper tools. It would be most helpful to get some aid from OpenRC team. I believe that some common-use tools written for the project could be used and tested in OpenRC first. And that way, slowly a new init system could enter the world. Sadly, it would be strictly bound to file formats and names set by systemd team. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] pid 1 design
Michał Górny mgo...@gentoo.org writes: Considering that systemd unit files are sometimes shipped with upstream packages, and often they are practically equivalent to openrc init scripts, I'd rather see openrc supporting that file format as an extension and using it instead of duplicating the same thing in init.d scripts. I bet this resonate with many minds out here. I am also planning to make a draft implementation. And yes, that means that people masking service files shoot themselves in the foot. Also, if I had more time (or support), I'd probably start working on a systemd-compatible init system with a more portable design. pgp74E5qQ6JNA.pgp Description: PGP signature
