Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 25 May 2010, Simo Sorce wrote: I'd like to remember that there are *many* upstreams are going to resistant to this change. A lot of upstream projects need to be compatible to a lot of Linux and Unix systems, even old ones, so before they move they want guarantee that this is really going to be the next thing. That means that until most distributions start using systemd they are not going to do the work. So before it is rushed in it is paramount that tests are done with those application s that will not have systemd support and make sure there is not going to be regressions there. Even bigger question: The architecture has to be correct. Systemd is trying to solve dependencies between applications by considering simple FD activity (by acting as a proxy for applications). However, there almost certainly are more complex, logical dependencies which are not visible to systemd, and hence which apps will still have to deal with and resolve between themselves. In short, we will still need that app-layer. We need to consider how that impacts architecturally on the worth of solving a subset of problems in a lower layer. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: I'm not a real movie star -- I've still got the same wife I started out with twenty-eight years ago. -- Will Rogers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: timevariant GUI elements (Re: systemd (Was Re: tmpfs for strategic directories))
On Wed, Jun 02, 2010 at 11:25:56AM +0200, Roberto Ragusa wrote: Kevin Kofler wrote: Roberto Ragusa wrote: In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), I only know of 2 plasmoids triggering actions on mouse-over: Sorry, I didn't manage to explain me well. I'm referring to the vertical bar which popups at the left of right of _every_ plasmoid. The thing with the close button and which you can drag around to move the plasmoid. yes, found that also very confusing in the beginning. You realise that you can get rid of those when you lock the widgets (there is a shortcut for that). Locking the widgets has other disadvantages, like you cant drag anything onto desktop so you need to remember to unlock it. Which is the biggest problem I have with this feature. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Matt McCutchen wrote: Please be careful not to take Lennart's remark out of context. A server takes longer /than a desktop/ since it doesn't take full advantage of systemd; it doesn't take longer than without systemd, because presumably the SysV init emulation doesn't have a significant performance penalty. There is no disadvantage of systemd here. Oh, of course, sorry for not having made that clear. If you were just saying that it may be worth the effort at some point to optimize server boot time, that point is taken. Right. That's what I really meant. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-06-02 at 07:58 +0200, Kevin Kofler wrote: Dave Airlie wrote: So does gdm use multiple X servers, I wasn't aware there was any other way. So what does it do exactly? Spawn a new X server on the same vterm? Or on a different vterm? What KDM does is to spawn a new X server on a different vterm. New X server on a different VT. I'm unaware of plans to make it operate any different, though that might not mean people have plans I don't know about. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: timevariant GUI elements (Re: systemd (Was Re: tmpfs for strategic directories))
Kevin Kofler wrote: Roberto Ragusa wrote: In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), I only know of 2 plasmoids triggering actions on mouse-over: Sorry, I didn't manage to explain me well. I'm referring to the vertical bar which popups at the left of right of _every_ plasmoid. The thing with the close button and which you can drag around to move the plasmoid. It is basically a window title bar done vertically. The bad part is that it popups on mouse movement and creates active elements (buttons) just under your mouse by guessing that you want them. If you have a crowded screen with overlapping windows and plasmoids, you get this popups in your way when you just want to click on a near window. Tooltips in general have this problem (uncontrollable creation of obstructions), but in this case the tooltip even contains clickable elements, so you have to be careful to not click them by error. Be_careful = be_slow_and_think = bad_GUI_concept. The folder view popping up you cited is another bad example (but I was not thinking about that). You say it's only visualization, but it changes the context, in the sense that now my dropping the icon has a new meaning (something randomly changed under my pointer). If the change happens just an instant before I'm releasing the button, my jpg will not go into Friends, but into Friends/DiscardedPhotos. So what should I do? Be careful to not park my pointer on any active area while I'm thinking about where to place my jpg; and every folder is now an active area; my desktop has turned into minesweeper. :-) I think the original idea from Apple was to use the spacebar to enter the directory. That is perfectly acceptable. In my opinion every automatic element (popups and tooltips) should only be allowed to show inactive things (better yet if the obstruction is not complete, for example, by using partial opacity and, if we want to be smart, increasing the opacity when the mouse is near, for legibility). In no case this thing must have clickable items. In no case this thing must intercept clicks: if I click on it the click should go to the elements it is covering (that is where transparency helps), because those elements have earned my attention for some time, before the appearance of the little intruder. The mouse pointer should be blended _below_ the tooltip. Tooltips should just be semitransparent post-it notes attached to my monitor. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: This suggests to me that environment variables isn't the right way to do this. Environment variables are good for parameters that should be available to many processes. Command line parameters are better when the parameter is only meant for one specific process. I can see how looking up two environment variables may be a smaller patch than adding a parameter to the program's command line parser, but I still think it should be done with command line parameters. This is a valid point and we have pondered this for a while and in the end decided to use environ[] instead of argv[], simply because this allows us to use the same code for handling it in all daemons, while handling --listen-fds=xxx in argv would work for some daemons, but not for others. (i.e. some don't do long getopt, others do it with one dash only). To handle different command line syntaxes I would apply some simple macro substitution to the command line in the .service file, replacing for example the string %listen_FDs% (or some other syntax) with the number of sockets. One daemon could then have the parameter --listen-fds=%listen_FDs%, another could have -sockets=%listen_FDs% and a third could have -q %listen_FDs%. Also, quite a few projects (rsyslog for example) implement socket handling in loadable modules, where we have no access to argv[] but do have access to environ[]. I'd be surprised if any of those programs are designed such that they have no way of passing parameters to their modules. LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the original daemon is restarted but its children live on, then later some descendant process may get the same PID as the original daemon, and may try to handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is guaranteed to work over one that mostly works. Well, this is purely theoretical, since LISTEN_FDS should normally only be set for daemons that can actually handle this and hence as long as these are running none of their children can get the same PID. I'm afraid I don't understand what you mean with handle this. I thought at first that you meant that LISTEN_FDS should only be used for daemons that are known to clear it, but if that were the case you wouldn't have invented LISTEN_PID. Do you perchance mean that LISTEN_FDS should only be used in cases where all child processes will be killed if the daemon dies? Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 6/1/2010 5:45 AM, Lennart Poettering wrote: Guys, nobody wants to take away configuration options. You can edit the .service files too, and readjust things. You can even plug in shell scripts here and there and wherever it suits you. There are not plans to make configuration of systemd depndent on gcc or gdb. That is completely made up. Lennart Experience in Fedora says that radical changes, even when they achieve their goals, come at a cost. Let us say that we accept your main premises: systemd will be much faster, much more reliable, and a better expenditure of system resources. What we haven't seen from you is a list of what will be lost. 1) Is there anything that currently works which will suddenly stop working? (I am reminded of the cups discussion) 2) Are there tools that will be needed that don't exist yet (or worse, won't exist when systemd is rolled out). 3) Has there been a trial phase with system admins who don't frequent this list or your blog? They are likely to have needs that you haven't anticipated. 4) Is systemd compatible with the functionality of a rescue disk? (I am fishing because I don't know what to expect) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 02:52 +0200, Lennart Poettering wrote: On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote: environment variables are normally inherited when forking/execing. We want to make sure that only the process we actually start ourselves parses and handles LISTEN_FDS. We want to avoid that if this daemon might spawn some other process, it might get confused into handling LISTEN_FDS, although that env var wasn't actually intended for it. And hence we say that LISTEN_PID should be verified first, and only if it matches LISTEN_FDS should be handled. If you are mandating behavior in daemons, wouldn't it be simpler to mandate the daemon unsets LISTEN_FDS ? Yes, our reference implementation actually does that. But we didn't want to rely on that, simply because handling the environ[] array is so messy, since memory allocation is not clear and the whole thing is not thread-safe. In many case environ[] should probably be considered a read-only data structure during runtime. I beg to differ, at least if we're talking about languages where you are able to just let a single thread run (not sure about Java): Simply document that the daemon should read and unset LISTEN_FDS (using unsetenv() instead of messing with environ manually) while there is only a single thread. That is, if you really must use environment variables for passing that information... Others have mentioned it already: The environment is for information that is meant to be long-lived and shared between processes, it should be feasible to pass this information via a command line option instead. Even more so if handling of the environment is so messy. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote: KillMode=control-group → the entire cgroup is shot down KillMode=process-group → only the process group of the process we forked is shot down KillMode=process → only the process we forked is shot down KillMode=none → nothing is shot down And what is the default? KillMode=control-group for native services and KillMode=process-group for SysV services. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote: On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: This suggests to me that environment variables isn't the right way to do this. Environment variables are good for parameters that should be available to many processes. Command line parameters are better when the parameter is only meant for one specific process. I can see how looking up two environment variables may be a smaller patch than adding a parameter to the program's command line parser, but I still think it should be done with command line parameters. This is a valid point and we have pondered this for a while and in the end decided to use environ[] instead of argv[], simply because this allows us to use the same code for handling it in all daemons, while handling --listen-fds=xxx in argv would work for some daemons, but not for others. (i.e. some don't do long getopt, others do it with one dash only). Also, quite a few projects (rsyslog for example) implement socket handling in loadable modules, where we have no access to argv[] but do have access to environ[]. From looking at /etc/rsyslog.conf, rsyslogd already seems to have a means to pass configuration into its modules. Offering the same interface on the command line shouldn't be rocket science. LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the original daemon is restarted but its children live on, then later some descendant process may get the same PID as the original daemon, and may try to handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is guaranteed to work over one that mostly works. Well, this is purely theoretical, since LISTEN_FDS should normally only be set for daemons that can actually handle this and hence as long as these are running none of their children can get the same PID. Daemons are known to occasionally go down unplanned and as I read it, systemd is intended to restart them in that case. While child processes could then be killed off via the cgroup to which they belong, this is not always desirable, think of sshd and the children it forks for every login. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-06-01 at 04:13 +0200, Lennart Poettering wrote: On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: This suggests to me that environment variables isn't the right way to do this. Environment variables are good for parameters that should be available to many processes. Command line parameters are better when the parameter is only meant for one specific process. I can see how looking up two environment variables may be a smaller patch than adding a parameter to the program's command line parser, but I still think it should be done with command line parameters. This is a valid point and we have pondered this for a while and in the end decided to use environ[] instead of argv[], simply because this allows us to use the same code for handling it in all daemons, while handling --listen-fds=xxx in argv would work for some daemons, but not for others. (i.e. some don't do long getopt, others do it with one dash only). Also, quite a few projects (rsyslog for example) implement socket handling in loadable modules, where we have no access to argv[] but do have access to environ[]. From looking at /etc/rsyslog.conf, rsyslogd already seems to have a means to pass configuration into its modules. Offering the same interface on the command line shouldn't rocket science. LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the original daemon is restarted but its children live on, then later some descendant process may get the same PID as the original daemon, and may try to handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is guaranteed to work over one that mostly works. Well, this is purely theoretical, since LISTEN_FDS should normally only be set for daemons that can actually handle this and hence as long as these are running none of their children can get the same PID. Daemons are known to occasionally go down unplanned and as I read it, systemd is intended to restart them in that case. While child processes could then be killed off via the cgroup to which they belong, this is not always desirable, think of sshd and the children it forks for every login. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
What type of cgroup are you using? Does it impede the use of lxc for containers? Ie, the cgroup type that systemd needs to be able to be nested inside a container in a whole OS virtualization (think VPS / Virtual Private Server where each VPS has root in its container). systemd uses a named hierarchy without mounting any other subsystem. So no, it does not impede the use of lxc for containers. Dhaval -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 01.06.10 05:53, Mike Fedyk (mfe...@mikefedyk.com) wrote: On Tue, Jun 1, 2010 at 4:22 AM, Lennart Poettering mzerq...@0pointer.de wrote: On Tue, 01.06.10 01:56, Mike Fedyk (mfe...@mikefedyk.com) wrote: KillMode=control-group → the entire cgroup is shot down KillMode=process-group → only the process group of the process we forked is shot down KillMode=process → only the process we forked is shot down KillMode=none → nothing is shot down And what is the default? KillMode=control-group for native services and KillMode=process-group for SysV services. Lennart Ok, the defaults look good. What type of cgroup are you using? Does it impede the use of lxc for containers? Ie, the cgroup type that systemd needs to be able to be nested inside a container in a whole OS virtualization (think VPS / Virtual Private Server where each VPS has root in its container). I currently use openvz and lxc (which is similar but based on cgroups) is getting close to feature pairity. systemd shouldn't get in the way of being used within a container based on lxc... As Dhaval already pointed out we use our own, named hierarchy, independent of any controller. On top of that we use it recursively: i.e. if you run systemd it will create the service groups beneath the group it itself is running in. That means that systemd should not interfere with any other system (unless you tell it to do so, via some config item), and is nicely recursively stackable. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering (mzerq...@0pointer.de) said: Requires=basic.target sockets.target dbus.socket After=basic.target sockets.target dbus.socket What does this goop mean and why is it necessary? basic.target encapsulates the early boot process (kinda the same stuff rc.sysinit currently does). The Requires= make sure that this is pulled in by dbus.service. The After= makes sure that it has finished before we fork dbus. How are these evaluated differently that you'd need to list both 'Requires' and 'After', as opposed to just one? (I would think Requires would imply After.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote: Well, I really do not want to flame anyone, but please consider that the guy proposing the change already gave us pulseaudio, which promised the it will do anything you do now, just easier feature too. Ah, turning this into something personal. Love you too. This is not a personal attack and I want to explain. You will agree with me that pulseaudio caused a lot of complaints. (we do not discuss if motivated or unmotivated, here) That bad reputation unavoidably leads to weaker trust in your promised guarantees. The most painful parts of PA were mainly the underestimation of both peculiar use cases and impact of issues in related software (e.g. bugged alsa drivers). It is only natural to be worried about the same things (like lack of customizability) for this new init system. You *are* in a worse position than someone else when proposing a revolution in some critical part of the system. That's no personal offense. On the positive side you are now well aware of the risks you face, so you will probably play it better than someone else. I hope your new init system will be a great success and help you clean your name from the PA mess. I honestly hope so. We then discovered that some _trivial_ things where lost: - having multiple independent sound cards - having control of the mixer - having sound with no user logged in ... should I also mention latency, CPU usage, stability,...? You seem to have no idea what you are talking about. But anyway, let's not turn this into a discussion about PA. Don't need another one of those. I've been personally been burned by these issues, to the point of going 90% of the way of removing PA from the system (I'm currently running the unrecommended system-wide instance, I manually restart it in some cases, I use often pasuspender and for some things I know I have to turn if off completely). But I'm still on F10 and I read that pulseaudio has become better. Maybe I will be positively surprised when upgrading to F13. Linux must NOT be Windows. Linux must NOT be OS X. Well I for one think we can learn a lot from the competition. Open your eyes. There's a lot of good stuff in those other OS worlds, particularly in the designs of MacOS X. There's still so much they do better than we do. With must NOT I do not mean we have to be far, I mean we are not obligated to be near. In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), the fast-user-switching approach (the Unix way is to have multiple X servers). In conclusion, your innovation is certainly welcome in the Linux world, but disadvantages have to be properly weighted against advantages. If you only list advantages, people is rightly suspicious. You are trying to clarify things: I see you are replying to almost everyone on this thread and that effort has to be appreciated. You even replied to my mail, which you took for a personal attack (which, as I said as first sentence in this and the previous mail, was not). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 01.06.10 15:25, Bill Nottingham (nott...@redhat.com) wrote: Lennart Poettering (mzerq...@0pointer.de) said: Requires=basic.target sockets.target dbus.socket After=basic.target sockets.target dbus.socket What does this goop mean and why is it necessary? basic.target encapsulates the early boot process (kinda the same stuff rc.sysinit currently does). The Requires= make sure that this is pulled in by dbus.service. The After= makes sure that it has finished before we fork dbus. How are these evaluated differently that you'd need to list both 'Requires' and 'After', as opposed to just one? (I would think Requires would imply After.) Well, in systemd ordering dependencies are independent of requirement independencies. Explanation: A requires B means that when A is started B is started too, at the same time. A after B means that when A is started and B is started as well, then B is started first and only when that finished A is started too. Now, if you combine both, then you get A requires B + A after B, which means that when A is started we first start B and when that is finished wwe load A too. There are use-cases for all three cases listed above, so we thought we cover this in just two dependency types, instead of three. (And in fact actually, since we have requires and requisite too, this saves us quite a few additional types) Now, since base.target is pulled in by the default boot target anyway, one could argue that in this case an After= would suffice, and the requires= is redundant. But uh, on a logical level base.target is actually required, so we should list both elements I think. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Roberto Ragusa wrote: In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), I only know of 2 plasmoids triggering actions on mouse-over: * the folder view's popping up of subfolders. This is not an active action, it's just displaying stuff, I don't see how this is fundamentally different from a tooltip. You don't actually CHANGE anything in the folders or files without a mouse click, it just shows you stuff. * Lancelot's clickless mode. While those are true actions (i.e. they're active), this mode is a deliberate OPTION (i.e. it can be turned off) in a plasmoid which is not shown by default, nor even INSTALLED by default (it's in kdeplasma-addons). I don't think either is a real problem. the fast-user-switching approach (the Unix way is to have multiple X servers). FWIW, KDE/KDM uses the multiple X servers approach. There are advantages and drawbacks to either method. Unfortunately, the different approaches mean user switching doesn't work with KDE under GDM nor with GNOME under KDM, which is the only real problem I see in that area (and one of my semi-secret plans is to try to fix this at some point one way or the other, but I'm way too busy). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Lennart Poettering wrote: It's OK if a server takes a bit longer to boot. A longer boot time for your server means more downtime if you need to reboot your server for whatever reason. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-06-02 at 02:50 +0200, Kevin Kofler wrote: Lennart Poettering wrote: It's OK if a server takes a bit longer to boot. A longer boot time for your server means more downtime if you need to reboot your server for whatever reason. Please be careful not to take Lennart's remark out of context. A server takes longer /than a desktop/ since it doesn't take full advantage of systemd; it doesn't take longer than without systemd, because presumably the SysV init emulation doesn't have a significant performance penalty. There is no disadvantage of systemd here. If you were just saying that it may be worth the effort at some point to optimize server boot time, that point is taken. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-06-02 at 02:33 +0200, Kevin Kofler wrote: Roberto Ragusa wrote: In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), I only know of 2 plasmoids triggering actions on mouse-over: * the folder view's popping up of subfolders. This is not an active action, it's just displaying stuff, I don't see how this is fundamentally different from a tooltip. You don't actually CHANGE anything in the folders or files without a mouse click, it just shows you stuff. * Lancelot's clickless mode. While those are true actions (i.e. they're active), this mode is a deliberate OPTION (i.e. it can be turned off) in a plasmoid which is not shown by default, nor even INSTALLED by default (it's in kdeplasma-addons). I don't think either is a real problem. the fast-user-switching approach (the Unix way is to have multiple X servers). FWIW, KDE/KDM uses the multiple X servers approach. There are advantages and drawbacks to either method. Unfortunately, the different approaches mean user switching doesn't work with KDE under GDM nor with GNOME under KDM, which is the only real problem I see in that area (and one of my semi-secret plans is to try to fix this at some point one way or the other, but I'm way too busy). So does gdm use multiple X servers, I wasn't aware there was any other way. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, Jun 01, 2010 at 09:58:37PM +0200, Roberto Ragusa wrote: Lennart Poettering wrote: On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote: Well, I really do not want to flame anyone, but please consider that the guy proposing the change already gave us pulseaudio, which promised the it will do anything you do now, just easier feature too. Ah, turning this into something personal. Love you too. This is not a personal attack and I want to explain. You will agree with me that pulseaudio caused a lot of complaints. (we do not discuss if motivated or unmotivated, here) That bad reputation unavoidably leads to weaker trust in your promised guarantees. The most painful parts of PA were mainly the underestimation of both peculiar use cases and impact of issues in related software (e.g. bugged alsa drivers). It is only natural to be worried about the same things (like lack of customizability) for this new init system. You *are* in a worse position than someone else when proposing a revolution in some critical part of the system. That's no personal offense. On the positive side you are now well aware of the risks you face, so you will probably play it better than someone else. Regardless of how this applies in this case, don't forget that digging your way out of a big mess is a different way to build trust. Sooner or later we all screw up, knowing how a person handles screwups can be quite valuable. I hope your new init system will be a great success and help you clean your name from the PA mess. I honestly hope so. We then discovered that some _trivial_ things where lost: - having multiple independent sound cards - having control of the mixer - having sound with no user logged in ... should I also mention latency, CPU usage, stability,...? You seem to have no idea what you are talking about. But anyway, let's not turn this into a discussion about PA. Don't need another one of those. I've been personally been burned by these issues, to the point of going 90% of the way of removing PA from the system (I'm currently running the unrecommended system-wide instance, I manually restart it in some cases, I use often pasuspender and for some things I know I have to turn if off completely). But I'm still on F10 and I read that pulseaudio has become better. Maybe I will be positively surprised when upgrading to F13. for better or worse, released Fedora versions, especially = N-1 don't tend to see a lot of updates. Developer manpower seems to shift quite early to rawhide and/or upstream and there's a few packages that only see token efforts once the next release is out. Staying on a particular release is unfortunately not the solution to get real fixes into your system. Linux must NOT be Windows. Linux must NOT be OS X. Well I for one think we can learn a lot from the competition. Open your eyes. There's a lot of good stuff in those other OS worlds, particularly in the designs of MacOS X. There's still so much they do better than we do. With must NOT I do not mean we have to be far, I mean we are not obligated to be near. In recent times some stupid (IMHO) ideas have been adopted in Linux just to copy what others do. Just as examples: the control of desktop widgets in KDE4 (functional GUI elements modified by a mouse-over???), the fast-user-switching approach (the Unix way is to have multiple X servers). For every stupid (IMHO) idea there's people who disagree with the stupid, IMHO and sometimes even the idea part. Long term, all this is evolutionary and some ideas die off, others prevail. Unlike in nature, it is steered evolution though and you can help steer away from ideas you deem bad by talking to the upstream developers. Venting on a distribution list won't do a lot of difference. Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Dave Airlie wrote: So does gdm use multiple X servers, I wasn't aware there was any other way. So what does it do exactly? Spawn a new X server on the same vterm? Or on a different vterm? What KDM does is to spawn a new X server on a different vterm. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 15:42, James Findley (s...@gmx.com) wrote: It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. Actually the blog post is proposing exactly that, as I read it. And it seems not only that lots of other people read it the same way, but some even agree with it. No, this is not what is meant. So, the plan is (and much of this is actually implemented already) is to go through /etc/init.d and similar directories, and look at every script individually. Then, figure out the common parts, and see if we can perhaps implement that elsewhere and in C at some other place. Example: /etc/rc.sysinit mounts a lot of API filesystems (such as /proc, /sys, /dev). We can do that already in the init system, very early during boot, in C. If we do this (and we did) the code is much shorter, and nicer, and does not require forking or anything. Another example: /etc/init.d/autofs loads the autofs4 module and sets up permissions on /dev/autofs. Wouldn't it be nicer if this would be done outside of a shell script? And so we decided to do that and moved this into udev and module-init-tools: instead of loading the module manually and setting up the device nodes manually we just create the device nodes in advance and apply permissions to it via udev rules (like any other device node) and then autoload the autofs module on first access. (and this has already hit rawhide by now iirc) Another example: /etc/init.d/btseed and .../bttrack include some amazingly evil code to fake daemonization of a process with and disown, as well as privilege dropping in shell. We can cover that much nicer in systemd, and provide the right and clean daemonization it needs out of the box. And so we added just that to systemd itself. (i.e. there is a User= and option in the .service files and a Type= option that allows you to tell systemd to do the necessary daemonization properly.) And a fourth example: if you look at /etc/init.d/cups you'll find some code in there that tries to make sure that sun RPC doesn't take away the CUPS port numbers. (It also retriggers the printers in the udev sysfs tree, which seems to be very wrong, i really wonder what that is for. Anybody please enlighten me?) But the port number issue can easily be fixed by systemd allocating the port number right-away, and this we can easily cover in plain C in systemd itself via .socket units. And that's what we did. So, in summary: we go through the shell scripts and figure out piece-by-pice whether we can find a better, perhaps more generic place for it. And the right place could vary: it could be systemd itself (maybe a new option in .service is sufficient, like the Type= or User= option mentioned above) or udev or module-init-tools, or in the daemon code itself. And suddenly, after you did this you notice that in those shell scripts the only thing that remains is boilerplate code, more often than not just the simple code copied 1:1 from the fedora reference init script. And the boilerplate code is redundant if you use native .service files. So, there are no plans at all to replace the shell scripts 1:1 with their equivalents written in C. There will not be a shell-to-C compiler or anything like that. What we want to do (and already did for quite a few daemons now), is to replace many of the shell hacks by C code at better, more generic places of basic OS. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 14:08, Jon Masters (jonat...@jonmasters.org) wrote: I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. I *very* strongly agree also. I do change init scripts, but even more than this, I see a growing trend for Linux systems to be less friendly to user modification. We are not so smart that we should do this. Well, we won't take anything away from you: if we add an option to systemd itself, for something that was previously done manually in the init script, then this is just that: an option you can configure as much as you want, simply by editing the .service file. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, 27.05.10 07:15, Matthew Miller (mat...@mattdm.org) wrote: On Thu, May 27, 2010 at 10:10:35AM +0200, Harald Hoyer wrote: We mainly speek about rc.sysinit, which most of you don't touch, because it would be overwritten the next initscripts update anyway. I would never touch it with a permanent change, but I definitely make debugging changes to it often enough. That's not down to it being a shell script though; it's because it's a crufty mess. Two things: if we replace stuff like sysinit by proper C code things become less fragile and hence you need to debug less. and secondly, bash is actually a pretty shitty debugger, especially when there are a lot of scripts running in parallel. For debugging purposes we should offer better tools, and some of that we already implemneted: if you pass systemd.confirm_spawn=1 on the kernel command line you have the option to single-step through a serialized startup. Tools like that I believe are much more appropriate for debugging the startup process. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, 27.05.10 10:13, Chris Adams (cmad...@hiwaay.net) wrote: Once upon a time, Kevin Kofler kevin.kof...@chello.at said: Editing the code is the wrong way to make simple local changes. That is only true if you can anticipate every task every system admin will ever need to do with your tools. I've edited init scripts for multiple reasons. For example, I have multiple instances of some daemons running, so I'll make multiple copies of the init script and edit as needed for config/PID file locations, etc. Just because we want to do more stuff in C then in shell it doesnt mean things become less editable or configurable. So, when you previously edited the init script, you can now edit the (much shorter and simpler) .service file, adjusting the various options it offers you. If you previously maintained a modified copy of an existing init script, you can now just have a modified copy of a .service file. There's really nothing that changes here. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 19:39, Alexander Boström (a...@root.snowtree.se) wrote: ons 2010-05-26 klockan 10:01 +0100 skrev James Findley: It's really not at all uncommon for me to need to modify an init script. There would be much rage if in order to do this I had to download the SRPM, extract the init code, figure out what I needed to change, modify it, recompile then install. Various ways to deal with that: 1. Change the Exec=/usr/libexec/food to ExecStart=/usr/local/sbin/foodwrapper Yes, that works well. 2. Add some hook support in the systemd config files. We actually have that in place already. You can hook in as many shell scripts as you want, like this: ExecStartPre=/some/shell/script/to/run/before/the/daemon ExecStartPost=/some/shell/script/to/run/after/the/daemon ExecStopPre=... ExecStopPost=... 3. Add support for switching specific services back to using the initscript even when booting with systemd. You can easily do that, simply by renaming the .service file. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 19:54, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le mercredi 26 mai 2010 à 19:39 +0200, Alexander Boström a écrit : ons 2010-05-26 klockan 10:01 +0100 skrev James Findley: It's really not at all uncommon for me to need to modify an init script. There would be much rage if in order to do this I had to download the SRPM, extract the init code, figure out what I needed to change, modify it, recompile then install. Various ways to deal with that: 1. Change the Exec=/usr/libexec/food to ExecStart=/usr/local/sbin/foodwrapper Won't work since one of the main things current scripts do is run some code as root, and some other code as the target user. We already cover for that. You can set PermissionsStartOnly=yes in the .service file. Then, only the program specified in ExecStart= will be started with reduced permissions (i.e. with dropped priviliges, reduced caps, yadda yadda), and everything in ExecStartPre= and friends will run as normal root user. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 09:08, Seth Vidal (skvi...@fedoraproject.org) wrote: Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. And given my experience dealing with actual real-world designed daemons and other such things, I'd say we've shown no ability to 'properly' design them and won't be showing that anytime soon. So since we have to live in the world, let's not go shooting our feet off. Well, this sounds like an ad for systemd: since it is hard to get writing daemons right, we have tought systemd a lot of tricks so that what you need to do for proper daemonizations is near to zero. systemd can do a lot of stuff for you, the forking, the supervising, the dropping of privs, the setting up of a clean working environment and more. Also, PID files are unnecessary with systemd. In effect writing a daemon becomes very easy then, because the environment will be set up completely for you right-away. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 09:53, Andrew Parker (andrewpar...@bigfoot.com) wrote: I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. I don't edit them, but I do frequently look at them to see what they're doing/why they aren't doing something/what config files i can add/edit to change behaviour etc. actually, i do edit them sometimes to add a temporary -x to them. sure as heck beats gdb. But the question is whether it beats systemd's kernel opts such as systemd.confirm_spawn= or systemd.log_level=, which are much more useful to debug or trace the start-up of services. And again, nobody said anything of replacing the current shell scripts with identical equivalents written in C. There will be no shell-to-C compiler or any such madness. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 12:49, Matthew Miller (mat...@mattdm.org) wrote: On Wed, May 26, 2010 at 06:39:43PM +0200, drago01 wrote: Again the sysadmin case just implies that something *else* is broken. Sure. As a distribution, we don't have control over upstream projects and their assumptions for daemon startup, shutdown, status, etc. Sometimes, they want odd things. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. If you think you can get every open source / free software project to agree on completely consistent behavior, or if you can create a text-format config file for your compiled daemon handler which handles every unanticipated case, well, okay. But it seems unlikely. (And that's not even considering running non-free software, which, while something I try to avoid, is a reasonable real-world use.) Well, if we cannot get rid of all shell scripts that is fine. If we can get rid of 90% of them a lot is achieved already. And to me it looks much more like 98% of the scripts that can be removed without ill-effect if systemd is used. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 10:16, Casey Dahlin (cdah...@redhat.com) wrote: Who is we? Upstart has about 1.7 developers. The 1 is Scott, myself and Johann Kiviniemi fight over the .7. the bzr history tells a different story. The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. Well, how exactly you set up the groups is up to you, but the way we do it in systemd is stick every service in a seperate cgroup, plus every user in a seperate one, too. Some examples: snip And so on. Someone else already pointed out the issues here. Hmm, where? enforcement for your services, since you simply have no cgroups. And no nice interfacing with the other libcgroup tools either. There's no reason Upstart couldn't offer cgroups for resource limits, its just passed them up as a process supervision mechanism. And they are broken for the screen case, though perhaps that could be fixed in the kernel. They are not broken for the screen case, and there is no fixing in the kernel necessary. Scott is simply a bit confused about cgroups, there is no screen problem. Well, for once, it would be nice to judge things due to actually existign features, not of big plans nobody is working on as you apparently admit outright. You worked on it, and finished it. You just didn't do it within Upstart. The manpower was there it was just misapplied. Well, in my blog story I tried to explain why we started anew, instead of fixing Upstart. Won't repeat this here. And then, the socket activtion is nice for various reasons, and lazy-loading is just one of them. The bigger advantage is that it does automatic dependency handling -- which of course is nothign that really fits into upstart's design, since that is based on events not dependencies -- events are just broken, as I might note. And adding dependency would turn around upstart's design, making it a completely different beast. Event-driven in Upstart's case just talks about the internal operation of Upstart. Its rather exposed in current iterations but its just a design philosophy. You can implement dependencies within it, though in the past Upstart has been hesitant with the term because it tends to imply a dependency-solving algorithm, where as Upstart provides its dependencies reactively, in response to change. Ah, if events are hidden from the outside in upcoming versions, then Upstart will become a completely different beast, and reinvent itself another time completely. Are you sure Upstart is really ready for use if every version is a complete redesign of what was before, and a departure from the core design paradigm that the old versions followed? Yes, really. MacOS could do it, and so can we. Its not that hard. And as I my add here I already hacked up a big part of it now for the servcies we start by default. Good for Apple? Maybe now they can design a better kernel? This is linux. We configure our systems here. Well, no need to shut your eyes that Apple is really good at some things. We should learn from them where it is a good idea. And here they are a positive example we can be inspired of. OK, I am listening. What's flawed about systemd? I wrote very detailed explanation why Upstart is just wrong in its core design. Please be so kind and be more specific if you claim the same abotu systemd, because otherwise all you are doing is spreading FUD. Apart from the issue of circular dependencies, which I know you've already had explained to you, I'd like to see how you intend to manage, say Circular dependencies? I don't think I heard that from you ever. Please explain? I mean, dependencies are dependencies. Whether they are configured manually or implicitly doesn't have any effect on the fact that they are there or not there. So if there is a dep loop with systemd in place there is a dep loop without systemd too. So please, elaborate on this, and tell me exactly what you mean by this. Veritas clustering products. Like it or not there are systems out there running software that's unstable, not open source, written by people who don't like you, will /never/ take your socket passing patch and would probably find clever ways to break or do it wrong if they did (yes, because of a 10-line patch). And, so? They can stay sysv init scripts just fine. Upstart doesn't ask anything of the userspace it intends to manage, and that userspace is a harsher place than you seem to realize. Neither do we ask anything. Socket actviation is cool, and a nice way to make things more robust and faster. But it's an optional feature. You don't have to use it. We support classic non-socket activation too, and we support classic Sysv too. Lennart -- Lennart PoetteringRed Hat, Inc. lennart
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 08:19, Jeff Spaleta (jspal...@gmail.com) wrote: On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering mzerq...@0pointer.de wrote: In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. So in other words... we are going to have a knockdown dragout over default unit config for a systemd enabled gdm and for anything that allows shell loginsjust not today. I don't think the will be much fuss about this, as I personally think that we should continue with the current behaviour here, and support screen out-of-the-box. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 09:01, Jeff Spaleta (jspal...@gmail.com) wrote: On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering mzerq...@0pointer.de wrote: Well, that depends on configuration. In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. Do you have a service file example yet in systemd git that can be used to get an understanding of the various configuration options which determine what gets killed and what doesn't? Nope, not really. But it is as easy as this: when we stop a service the KillMode= option controls whether and how any processes remaining after the ExecStop= command (if there is such a command, and if there are any processes left) is killed. KillMode=control-group → the entire cgroup is shot down KillMode=process-group → only the process group of the process we forked is shot down KillMode=process → only the process we forked is shot down KillMode=none → nothing is shot down Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 12:57, Colin Walters (walt...@verbum.org) wrote: On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering mzerq...@0pointer.de wrote: http://0pointer.de/public/dbus.service. Note the ExecStartPre here, like most daemons, is conceptually busted. There's no reason we shouldn't lay that file down once when the OS is installed, and not check it every boot. Or alternatively, just move the uuid generation into the daemon itself. I think it kinda makes sense to to leave the uuid generating for the first boot, simply to make it easy to generate a hdd image during installation which can tzhen be booted from various machines, where each of them will then get its own uuid. But yes, I too think that dbus itself should just create that uuid on startup. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 13:08, Colin Walters (walt...@verbum.org) wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? THERE ARE NO PLANS TO SHIP COMPILED INIT SCRIPTS OR ANYTHING LIKE THAT! The plan is to reduce what is currenlty done in files like /etc/init.d/messagebus to files like http://0pointer.de/public/dbus.service. Also: Description=D-Bus System Bus This seems unnecessary. Can we default to the name of the script? If this isn't translated, I don't see how it's more interesting than just dbus. Later on this shall be translatable, the same way as the Comment field of .desktop files. And if you omit this option we'll already default to the unit name, the way you suggsted. Requires=basic.target sockets.target dbus.socket After=basic.target sockets.target dbus.socket What does this goop mean and why is it necessary? basic.target encapsulates the early boot process (kinda the same stuff rc.sysinit currently does). The Requires= make sure that this is pulled in by dbus.service. The After= makes sure that it has finished before we fork dbus. And ignore the sockets.target/dbus.socket stuff, that I had in there for debugging only. It's not necessary, and completely redundant. It will not be in the final version of this .service file. The reason why basic.target is explicitly mentioned in the .service file is that we want to handle early boot and normal daemon start-up with the same .service files. This is different from launchd for example, where early boot is basically a shell script handled completely independently and differently from normal services. I think we need more flexibility there, simply because we have to cover way more than Apple has to when it comes to plugging something into early boot. The price for that is that normal daemons that are started in late boot, have to add these Requires= and After= lines for basic.target. This felxible design has various other advantages too, for example we can blur the destinction between early and late boot a bit and remove the synchronization point that seperates them, for selected services. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 12:27, Adam Williamson (awill...@redhat.com) wrote: The plan is to reduce what is currenlty done in files like /etc/init.d/messagebus to files like http://0pointer.de/public/dbus.service. And those files you can edit just fine, and reconfigure. There's no need to yell, you only explained that a couple of minutes ago, before I wrote the above mail. From your blog post, it sounded very much like compiled initscripts were what you were proposing. This seems perfectly reasonable, but at the same time, when you explain it this way, it doesn't seem like anything that needs a new init system to happen. You can move stuff into the daemons themselves no matter what init system you're using, and it seems like upstart would be open to moving appropriate things into the init system. That does seem like a perfectly sensible thing to do, though, so I hope it happens, whatever init system we wind up with. Well. Sure. Upstart can copy every feature we have. But while all of this is still in the future for Upstart we already have implemented a fair bit of it in systemd. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 14:47, Simo Sorce (sso...@redhat.com) wrote: environment variables are normally inherited when forking/execing. We want to make sure that only the process we actually start ourselves parses and handles LISTEN_FDS. We want to avoid that if this daemon might spawn some other process, it might get confused into handling LISTEN_FDS, although that env var wasn't actually intended for it. And hence we say that LISTEN_PID should be verified first, and only if it matches LISTEN_FDS should be handled. If you are mandating behavior in daemons, wouldn't it be simpler to mandate the daemon unsets LISTEN_FDS ? Yes, our reference implementation actually does that. But we didn't want to rely on that, simply because handling the environ[] array is so messy, since memory allocation is not clear and the whole thing is not thread-safe. In many case environ[] should probably be considered a read-only data structure during runtime. If I replace the process with a script, or the dameon runs other processes LISTEN_PID is going to be wrong anyway, not sure how useful it really is. Nah, as long as the script calls exec() in the end it should be fine, as the PID isn't changed on exec(). Note that for the purpose of baby-sitting it is kinda nice to know which process is the main process of a daemon, hence needless fork()ing on startup sucks anyway, and should better not be done if we can. You are assuming that the process you run is always going to be *the* daemon. I think it is an unrealistic assumption to make. Oh, its very much realistic I think. It holds for every single of the 10 daemons or so from the default F13 install and beyond I have patched so far. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 18:02, Scott James Remnant (sc...@canonical.com) wrote: On Wed, 2010-05-26 at 18:14 +0200, Lennart Poettering wrote: Oh come on. Thanks for turning this into something personal. You did that last week - I got forwarded logs from #systemd. That's probably why I wasn't in a great mood with you this morning ;-) Not sure what you are referring to. I'm not sure there's any point in technical discussion about the relative merits of our two approaches at this point, since you've already *written* systemd and you're already pushing for inclusion in distributions, and I'm continuing to develop Upstart and already have it in distributions. Well, the members of this mailing list are definitely interested in the relative merits of both systems, since it is people on this mailing list who in the end will have to come up with an informed decision about systemd adoption in Fedora. I mean, I have been writing novels here about how awesome systemd is (and how upstart isn't ;-)). If you think that Fedora would make a big mistake in adopting systemd, then please point out why, I am pretty sure people will listen if you keep things technical. It's always good to hear both sides when a decision needs to be made. So what we've ended up with is two different systems, and one can assume that roughly half the distributions will end up with one, and another half with the other. Well. We'll see about that. At least we have the common standard of the LSB Init Scripts that both will support. Well, it would be good if we'd have more than that. Since you want to support socket-based activation too now in Upstart it would be great if we could also come to an agreement on the $LISTEN_FD iface and similar. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 22:06, Björn Persson (bj...@rombobjörn.se) wrote: This suggests to me that environment variables isn't the right way to do this. Environment variables are good for parameters that should be available to many processes. Command line parameters are better when the parameter is only meant for one specific process. I can see how looking up two environment variables may be a smaller patch than adding a parameter to the program's command line parser, but I still think it should be done with command line parameters. This is a valid point and we have pondered this for a while and in the end decided to use environ[] instead of argv[], simply because this allows us to use the same code for handling it in all daemons, while handling --listen-fds=xxx in argv would work for some daemons, but not for others. (i.e. some don't do long getopt, others do it with one dash only). Also, quite a few projects (rsyslog for example) implement socket handling in loadable modules, where we have no access to argv[] but do have access to environ[]. LISTEN_PID isn't bullet-proof by the way, because PIDs are reused. If the original daemon is restarted but its children live on, then later some descendant process may get the same PID as the original daemon, and may try to handle LISTEN_FDS. The risk may be low, but I always prefer a solution that is guaranteed to work over one that mostly works. Well, this is purely theoretical, since LISTEN_FDS should normally only be set for daemons that can actually handle this and hence as long as these are running none of their children can get the same PID. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 13:37, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: On 05/26/2010 12:07 PM, Adam Williamson wrote: It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? It could work out if systemd provided access to a system() equivalent which could then execute an arbitrary script. You can easily hook shell scripts into .service files via stuff like ExecStartPre=/some/shell/script which will then be executed before the actual daemon is forked off. I think one good argument for redoing initscripts is that they are so repetitive: most of the content is fairly standard: initialization, argument parsing, case $1 in start) stop), etc etc. ; stuff that might as well be done in the common framework. That is true. Most scripts are 1:1 copies of the init script template of our guidelines. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Sat, 29.05.10 19:27, Roberto Ragusa (m...@robertoragusa.it) wrote: Kevin Kofler wrote: Jon Masters wrote: Didn't we decide that Fedora was intended for more technical users? I don't see many technical users crying out for a hammered shut init system where they feel like they have to go to their auto mechanic to attach the right magic dongle to fix it when it breaks. A really TECHNICAL user has no trouble editing a C program. :-) On a router? With no gcc installed? And with no disk space to install gcc? And with no network available? (because, you know, I'm fixing the router which is failing to boot properly) Guys, nobody wants to take away configuration options. You can edit the .service files too, and readjust things. You can even plug in shell scripts here and there and wherever it suits you. There are not plans to make configuration of systemd depndent on gcc or gdb. That is completely made up. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Sat, 29.05.10 19:48, Roberto Ragusa (m...@robertoragusa.it) wrote: Kevin Kofler wrote: Jeremy Sanders wrote: You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. C code can be changed too, if really needed. But the point is that it should not be necessary to edit code at all to get what's needed. Well, I really do not want to flame anyone, but please consider that the guy proposing the change already gave us pulseaudio, which promised the it will do anything you do now, just easier feature too. Ah, turning this into something personal. Love you too. We then discovered that some _trivial_ things where lost: - having multiple independent sound cards - having control of the mixer - having sound with no user logged in ... should I also mention latency, CPU usage, stability,...? You seem to have no idea what you are talking about. But anyway, let's not turn this into a discussion about PA. Don't need another one of those. Linux must NOT be Windows. Linux must NOT be OS X. Well I for one think we can learn a lot from the competition. Open your eyes. There's a lot of good stuff in those other OS worlds, particularly in the designs of MacOS X. There's still so much they do better than we do. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Sat, 29.05.10 21:00, Roberto Ragusa (m...@robertoragusa.it) wrote: Kevin Kofler wrote: Roberto Ragusa wrote: I need to change firewalls rules and routing rules in the middle of the init scripts, because I have a multihomed internet connection and remote filesystems and I need the firewall closed and then opened in a way which is dependent on the IP I got from the ISP Ugh! Are you sure there's no better solution?! Kevin, this is not an exactly real scenario, but I wanted to say that sometimes it is useful to *hack* something in the middle of the init script for some reason. And this is why systemd allows you to do that. You can patch the .service files the way you want, and can hook shell scripts into various places, if you want to. And on top of this it adds a couple of debug helpers such as interactive, serialized boot-up and proper tracing of what is being executed. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/23/2010 05:21 AM, Lennart Poettering wrote: On Sun, 23.05.10 00:04, Ilyes Gouta (ilyes.go...@gmail.com) wrote: Heya, So how fast is a systemd boot (with all the changes to the scripts) compared to the current F13 setup? How about a ratio? Please be patient. To quote myself: I'll publish the numbers of a 100% socket-activated boot soon. To get the ball rolling, I have written up a feature proposal and filed a review request https://fedoraproject.org/wiki/Features/systemd https://bugzilla.redhat.com/show_bug.cgi?id=598299 It probably requires a lot more work but it is a start. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Kevin Kofler wrote: Jon Masters wrote: Didn't we decide that Fedora was intended for more technical users? I don't see many technical users crying out for a hammered shut init system where they feel like they have to go to their auto mechanic to attach the right magic dongle to fix it when it breaks. A really TECHNICAL user has no trouble editing a C program. :-) On a router? With no gcc installed? And with no disk space to install gcc? And with no network available? (because, you know, I'm fixing the router which is failing to boot properly) I hope your smiley face means you are joking. :-) -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Sat, May 29, 2010 at 07:27:57PM +0200, Roberto Ragusa wrote: Kevin Kofler wrote: Jon Masters wrote: Didn't we decide that Fedora was intended for more technical users? I don't see many technical users crying out for a hammered shut init system where they feel like they have to go to their auto mechanic to attach the right magic dongle to fix it when it breaks. A really TECHNICAL user has no trouble editing a C program. :-) On a router? With no gcc installed? And with no disk space to install gcc? And with no network available? (because, you know, I'm fixing the router which is failing to boot properly) I hope your smiley face means you are joking. :-) A bad kernel or glibc could cause your system to fail to boot properly. Does that mean we should include all the source code for the kernel and glibc on the system? No. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Kevin Kofler wrote: Jeremy Sanders wrote: You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. C code can be changed too, if really needed. But the point is that it should not be necessary to edit code at all to get what's needed. Well, I really do not want to flame anyone, but please consider that the guy proposing the change already gave us pulseaudio, which promised the it will do anything you do now, just easier feature too. We then discovered that some _trivial_ things where lost: - having multiple independent sound cards - having control of the mixer - having sound with no user logged in ... should I also mention latency, CPU usage, stability,...? Come on, it took a couple of years to have a decently working audio system back. Now, should I really believe that the new compiled but it will do anything init system will be able to help me when ...don't know... I need to change firewalls rules and routing rules in the middle of the init scripts, because I have a multihomed internet connection and remote filesystems and I need the firewall closed and then opened in a way which is dependent on the IP I got from the ISP and I need a sleep 5 in a proper place because the ADSL modem is still booting its firmware and I want some output printed to /dev/tty1 during boot and I want some filesystems to be mounted with mount because they take time but only contain data not needed to boot and ? This stuff can be trivially done by a competent sysadmin with shell-based init scripts and vi. Linux must NOT be Windows. Linux must NOT be OS X. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Roberto Ragusa wrote: - having control of the mixer The KMix ALSA backend is not going away. https://fedoraproject.org/wiki/Features/KDE_PulseAudio_Integration#Release_Notes I need to change firewalls rules and routing rules in the middle of the init scripts, because I have a multihomed internet connection and remote filesystems and I need the firewall closed and then opened in a way which is dependent on the IP I got from the ISP Ugh! Are you sure there's no better solution?! and I need a sleep 5 in a proper place because the ADSL modem is still booting its firmware This is a completely broken workaround for a bug somewhere. The driver needs to wait for the firmware to be loaded before reporting ready status, and network startup should not report being complete before the driver is ready. We need to get the bug fixed so this works out of the box for everyone! sleep is always a bad and unreliable way to do synchronization. Plus, you're blocking the whole system startup for 5 seconds rather than just what depends on networking, because neither SysVInit nor Upstart's SysVInit compatibility mode are capable of parallel booting (whereas systemd is, even in SysVInit compatibility mode thanks to LSB initscript headers, but even more so with native configuration which Lennart is writing). and I want some output printed to /dev/tty1 during boot You can probably set up simple systemd config files for that using the dependency system, but… ugh! and I want some filesystems to be mounted with mount because they take time but only contain data not needed to boot This point is moot with a parallel init system such as systemd! ALL mounts in systemd are background tasks, and autofs magic is used to block accesses to mountpoints which are not ready until they become ready. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Kevin Kofler wrote: Roberto Ragusa wrote: I need to change firewalls rules and routing rules in the middle of the init scripts, because I have a multihomed internet connection and remote filesystems and I need the firewall closed and then opened in a way which is dependent on the IP I got from the ISP Ugh! Are you sure there's no better solution?! Kevin, this is not an exactly real scenario, but I wanted to say that sometimes it is useful to *hack* something in the middle of the init script for some reason. I know that no sleep 5 should be there to wait for the firmware of the ADSL modem and so on... what I'm trying to say is that in some cases you need to do something dirty to work around a bug or to confirm a bug. For example, I had really bad luck with the rt2500 driver having weird crashes with the ordering and relative timing of modprobe, ifconfig up, iwconfig. Understanding what the hell was happening during boot (and only during boot) made me add strange hacks into the scripts so to be able to describe the bug. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, 2010-05-27 at 15:39 +0200, Kevin Kofler wrote: Jeremy Sanders wrote: You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. C code can be changed too, if really needed. But the point is that it should not be necessary to edit code at all to get what's needed. I'm sure we could live in a wonderful Utopia in which everything just works and there are pink butterflies everywhere, but in the *real* world (the same one where not every software update works first time), repeatedly, people have pointed out that this is not the case. Didn't we decide that Fedora was intended for more technical users? I don't see many technical users crying out for a hammered shut init system where they feel like they have to go to their auto mechanic to attach the right magic dongle to fix it when it breaks. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Jon Masters wrote: Didn't we decide that Fedora was intended for more technical users? I don't see many technical users crying out for a hammered shut init system where they feel like they have to go to their auto mechanic to attach the right magic dongle to fix it when it breaks. A really TECHNICAL user has no trouble editing a C program. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
drago01 wrote: Well spawing your logic further means we should avoid compiled programs at all, what if I want configure $app by editing its source code? Oh wait it is written in C ... If it goes down to want to edit scripts for configuration reasons (which isn't sane anyway) compared to a faster an cleaner boot process I'd opt for the later. Seriously source code is NOT and never was intended to be a configuration system period. It's a great advantage to have non-compiled programs on the system which can be edited: - Debugging packaged python programs - Customizing user interfaces - Understanding logic and parameters That's speaking as a developer and someone who does some sysadmin work. The overhead of a simple scripting language like Lua, awk, Python or Perl is minimal compared to the fork cost. You won't notice the difference between a Lua startup script and a C one. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Bill Nottingham wrote: Jeremy Sanders (jer...@jeremysanders.net) said: Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. If you're going to want them to be editable to pass the lowest-common-denominator test of whatever admins might be editing them, I think bash is probably the only reasonable choice. Perhaps, though C is completely non editable to many sysadmins and lacks easy to use builtin routines helpful in scripting (maps, lists, tuples, string manipulation). At least a simple Lua script should be comprehensible to the average sysadmin in case they need to debug or trace something, even if they never write anything. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
drago01 wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. Again the sysadmin case just implies that something *else* is broken. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. What rubbish. For instance, we customised an early Fedora to work on a diskless NFS rooted system, mainly by mucking around with init scripts. Being able to easily edit these files made this project work and work quickly. Trying to get upstream to special case our particular setup wouldn't have happened. You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. There is a clear case for having an open and completely configurable system. It's not going to cost 1 sec of bootup either. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/26/2010 02:54 PM, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -sv We mainly speek about rc.sysinit, which most of you don't touch, because it would be overwritten the next initscripts update anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/26/2010 06:07 PM, Adam Williamson wrote: On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlincdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? unless you want rc.sysinit changes, you would have no problem with systemd to modify the system to your needs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, May 27, 2010 at 10:10:35AM +0200, Harald Hoyer wrote: We mainly speek about rc.sysinit, which most of you don't touch, because it would be overwritten the next initscripts update anyway. I would never touch it with a permanent change, but I definitely make debugging changes to it often enough. That's not down to it being a shell script though; it's because it's a crufty mess. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Chris Adams wrote: No, it isn't. It makes the process much more opaque to system administrators and makes it harder to make quick fixes and simple local changes. Editing the code is the wrong way to make simple local changes. If there isn't a measurable and significant speed improvement, it is definately a waste of time to replace working scripts. According to the explanations given elsewhere in the thread, the idea is to have much of the stuff done directly inside the init system instead of softcoding (cf. http://en.wikipedia.org/wiki/Softcoding, http://thedailywtf.com/Articles/Soft_Coding.aspx) it as scripts. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, May 27, 2010 at 03:14:54PM +0200, Kevin Kofler wrote: That's not down to it being a shell script though; it's because it's a crufty mess. … which is exactly why it should be handled inside the init system instead of being that mess of a shell script. :-) Maybe. That cruft is all there for a reason, and it'll take a lot of work to disentangle the good reasons from the ones that should be left behind. Putting it all in an opaque binary seems _less_ conducive to that rather than more. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Thu, May 27, 2010 at 9:56 AM, Jeremy Sanders jer...@jeremysanders.net wrote: drago01 wrote: [..] You're suggesting hammering shut the insides of linux to stop people playing around and reducing freedom - sounds like you want Fedora to be like the products of other large propitiatory systems. What? You can edit it anytime it is OPEN SOURCE ( you have the freedom to do whatever the OSS license used allows you *including* editing). Configuration is not supposed to be done by editing code. The whole C vs. bash aside, even editing bash scripts which are part of the system for _configuration_ reasons is *wrong*. Separating source code and configuration is just well designed software not non free software. Anyway I am done with this discussion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 04:02, Casey Dahlin wrote:
On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
On 05/23/2010 04:19 AM, Kevin Kofler wrote:
Lennart Poettering wrote:
So far response from the community has been very positive, but we didn't
have a fedora-devel discussion about this yet, so we'll have to see
whether we can somehow make the broader community as enthusiastic about
the whole idea as I am. ;-)
I, for one, think systemd should be the default ASAP.
Perhaps the first time I can recall that we have agreed. ;)
~spot
Any particular reason on either of your parts?
Just about everything in systemd is either set to be in upstart (simpler
dependency syntax, xinetd-style service activation) or was discarded by it
years ago (cgroups are a dead end).
Oh, is that so?
Have you actually read the blog story I put together?
Yes, but I'm going to go read it again just to be sure.
Why do you say cgroups are a dead end? Sure, Scott claims that, but
uh, it's not the only place where he is simply wrong and his claims
baseless. In fact it works really well, and is one of the strong points
in systemd. I simply see no alternative for it. The points Scott raised
kinda showed that he never really played around with them.
Please read up on cgroups, before you just dismiss technology like that
as dead end.
I did. When upstart was about to use them. 2 years ago. We chucked them by the
following LPC.
The problem we've found is that cgroups are too aggressive. They don't have a
notion of sessions and count too much as being part of your service, so you
end
up with your screen session being counted as part of gdm.
This is why setsid was added to the netlink connector.
The assumption that just because its new means its more advanced is in this
case a bit misguided.
Well, please read the blog story. I know it's long, but it should be an
interesting read. The whole point of the blog story is to make clear the
reason systemd exists is purely technical, and that we think our design
is simply the better one.
So you have:
1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence the
rest of Upstart, but a socket activation subsystem that could reach as far as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.
2) Bus activation. Missed opportunity here to actually become the launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying to
bludgeon Marcel Holtmann into turning over to the public for a year now.
3) Cutting down on the forking by replacing some of the shell scripts... cool
3a) With C code... really?
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about. But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts wait. Something is wrong with
that picture ;)
Modern systems just don't take very long to spawn awk. Or sed. Or cut.
Or bash. IMO this sort of tradeoff between speed and ease of use hasn't
been appropriate in 20 years.
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
The rest of systemd looks great to me - and the sooner we can switch the
lesser the pain in some respects (as the longer we wait, the more used
people become to upstart, and then we have to switch again, causing user
frustration).
-siXy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
James Findley wrote: Modern systems just don't take very long to spawn awk. Or sed. Or cut. Or bash. IMO this sort of tradeoff between speed and ease of use hasn't been appropriate in 20 years. It's really not at all uncommon for me to need to modify an init script. There would be much rage if in order to do this I had to download the SRPM, extract the init code, figure out what I needed to change, modify it, recompile then install. Absolutely. I remember something similar with hal-disk-something, related to mount options. One day everything got switched to compiled code and manageability approached zero. -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 11:12, Bastien Nocera wrote:
On Wed, 2010-05-26 at 10:01 +0100, James Findley wrote:
On 26/05/10 04:02, Casey Dahlin wrote:
On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote:
On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote:
On Mon, May 24, 2010 at 09:05:31AM -0400, Tom spot Callaway wrote:
On 05/23/2010 04:19 AM, Kevin Kofler wrote:
Lennart Poettering wrote:
So far response from the community has been very positive, but we
didn't
have a fedora-devel discussion about this yet, so we'll have to see
whether we can somehow make the broader community as enthusiastic about
the whole idea as I am. ;-)
I, for one, think systemd should be the default ASAP.
Perhaps the first time I can recall that we have agreed. ;)
~spot
Any particular reason on either of your parts?
Just about everything in systemd is either set to be in upstart (simpler
dependency syntax, xinetd-style service activation) or was discarded by it
years ago (cgroups are a dead end).
Oh, is that so?
Have you actually read the blog story I put together?
Yes, but I'm going to go read it again just to be sure.
Why do you say cgroups are a dead end? Sure, Scott claims that, but
uh, it's not the only place where he is simply wrong and his claims
baseless. In fact it works really well, and is one of the strong points
in systemd. I simply see no alternative for it. The points Scott raised
kinda showed that he never really played around with them.
Please read up on cgroups, before you just dismiss technology like that
as dead end.
I did. When upstart was about to use them. 2 years ago. We chucked them by
the
following LPC.
The problem we've found is that cgroups are too aggressive. They don't have
a
notion of sessions and count too much as being part of your service, so you
end
up with your screen session being counted as part of gdm.
This is why setsid was added to the netlink connector.
The assumption that just because its new means its more advanced is in
this
case a bit misguided.
Well, please read the blog story. I know it's long, but it should be an
interesting read. The whole point of the blog story is to make clear the
reason systemd exists is purely technical, and that we think our design
is simply the better one.
So you have:
1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you
cared to submit the patch. We don't think its good enough by itself, hence
the
rest of Upstart, but a socket activation subsystem that could reach as far
as
systemd and even work standalone in settings where systemd can work is
perfectly within Upstart's scope. I'd be happy to firm up the design details
with you if you wanted to contribute patches.
2) Bus activation. Missed opportunity here to actually become the
launchpoint
for activated services. I won't criticize that too much though, as its
usefulness is largely dependent on kernelspace DBus, which I've been trying
to
bludgeon Marcel Holtmann into turning over to the public for a year now.
3) Cutting down on the forking by replacing some of the shell scripts...
cool
3a) With C code... really?
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about.
Now run a loop, in C, which does the same thing.
$ time ./foo /dev/null
real 0m0.002s
user 0m0.001s
sys 0m0.001s
You're comparing the wrong thing here - I was demonstrating that it
doesn't take noticeably longer to spawn awk than a small C app on modern
systems.
thus using:
for i in {1..1000}; do awk 'BEGIN{print Hello World}' /dev/null; done
for i in {1..1000}; do ./helloworld /dev/null; done
we compare how long it takes to start a trivial C program 1000 times to
a trivial awk program 1000 times.
The bash for loop overhead is present in both cases, and since we are
only interested in the difference in speed, we can ignore it. (I
actually ran this comparison a number of times, and used the mean value)
You're comparing how long it takes to launch an awk program 1000 times
to how long it takes to run 1000 iterations of a loop in C. This is not
an especially useful thing to do.
But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts wait. Something is wrong with
that picture ;)
There's no compiling of startup
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 25.05.10 23:02, Casey Dahlin (cdah...@redhat.com) wrote: Why do you say cgroups are a dead end? Sure, Scott claims that, but uh, it's not the only place where he is simply wrong and his claims baseless. In fact it works really well, and is one of the strong points in systemd. I simply see no alternative for it. The points Scott raised kinda showed that he never really played around with them. Please read up on cgroups, before you just dismiss technology like that as dead end. I did. When upstart was about to use them. 2 years ago. We chucked them by the following LPC. Who is we? The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. Well, how exactly you set up the groups is up to you, but the way we do it in systemd is stick every service in a seperate cgroup, plus every user in a seperate one, too. Some examples: /systemd-1/avahi.service /systemd-1/ge...@tty1.service /systemd-1/gdm.service /systemd-1/apache.service /user/lennart /user/cjd The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. In addition we can easily set all kinds of cgroup-based resource enforcement to these groups, i.e. force user lennart to CPU 1, and say that apache and all the cgi scripts it creates can only get up to 20% CPU. And avahi-daemon could be forced to get a quarter of the available RAM at max -- with all its processes summed up, regardless how often it might fork. And the whole thing is even recursive. If you run a per-user systemd as user lennart, you will end up with a sub-hierarchy like this: /user/lennart/systemd-4711/dbus-daemon.service /user/lennart/systemd-4711/dconfd.service And so on. And the nice thing is that these cgroups are shown when you do ps -eo cgroup, You can always figure out from ps to which service a process belongs, even if if it fork()ed a gazillions of times. And all the keeping track is done by the kernel, basically for free. No involvement from userspace. This is why setsid was added to the netlink connector. Well, this is just flawed, on so many levels, that it hurts. Asynchronously trying to follow how daemons fork/exit is just inherently broken because they can do an exponential amount of forks in the time you can (realisticly) collect them linearly only. Also, if a daemon forks too often, netlink willl drop your messages, which makes an easy-peasy way for processes to escape your supervision, using only inprivileged operations. You have constant userspace wakeups. Everything you apply on the processes is done asynchronously and hence is racy (killing, renice, yadda yadda). The problem is simply that your grip on the processes can never work, because you are scheduled at the same priority as the daemons you supervise and you get all notifications asynchronously. You *really* want to leave process tracking to the kernel, and not try to emulate that in userspace. Everything else is just unsafe and hence a joke in the context of process baby sitting. It's like if you'd employ a babysitter and give the kid a bike it can escape on while chaining your babysitter to the couch. So, it's just not safe, processes can *easily* escape your supervision. On top of that it is just ugly. And finally, you cannot nicely show the service something belongs to in ps the way cgroups give it to you for free. Then, you cannot set cgroup resource enforcement for your services, since you simply have no cgroups. And no nice interfacing with the other libcgroup tools either. Meh, and this lists gets on like this. People should not use cn_proc. It's evil. And if you are using for anything except logging you are doomed. And even for logging it isnt really useful. 1) Socket activation. Part of Upstart's roadmap. Would happen sooner if you cared to submit the patch. We don't think its good enough by itself, hence the rest of Upstart, but a socket activation subsystem that could reach as far as systemd and even work standalone in settings where systemd can work is perfectly within Upstart's scope. I'd be happy to firm up the design details with you if you wanted to contribute patches. Well, for once, it would be nice to judge things due to actually existign features, not of big plans nobody is working on as you apparently admit outright. And then, the socket activtion is nice for various reasons, and lazy-loading is just one of them. The bigger advantage is that it does automatic dependency handling -- which of course is nothign that really fits into upstart's design, since that is based on events not dependencies -- events are just broken, as I might note. And adding dependency would turn around upstart's design, making it a completely different
Re: systemd (Was Re: tmpfs for strategic directories)
On Tue, 2010-05-25 at 17:24 +0200, Lennart Poettering wrote: Can you point us to where any background discussion has taken place with Upstart folks? No, I cannot. Kay and I and a couple of others sat down at various LPC and GUADEC and discussed what we would like to see in an init system. And we had long discussions, but ultimately most of our ideas were outright rejected by Scott, such as the launchd-style activation and the cgroup stuff, two of the most awesome features in systemd now. (That said, we actually managed to convince him on other points, i.e. I believe we played a role in turning him from a D-Bus-hater into a D-Bus-lover). Sorry, but that's complete bullshit. We did sit down and discuss things, and you convinced me that launchd-style activation was a useful thing to have. Then you went off and wrote systemd anyway. And it was Ryan Lortie who convinced me that D-Bus was the right way to go very early on, the conversion of Upstart to D-Bus happened years ago (Fedora is lagging behind on versions so only just got that). So we have discussed this with Scott in much detail, and we have followed his development for a longer time. But in the end I just don't think Upstart is the right thing, and fundamentally flawed and unlikely to change direction, which is why we chose to start anew, and not just fix Upstart. For more about that just read my blog story. Given that I have changed direction a couple of times with Upstart, and have been swayed to different courses by a good argument, I refuse that it's unlikely to change direction ;-) I'm certainly more interested in getting Upstart *right* than in rushing to get it finished by a certain date. To be clear, I believe the reason you implemented systemd instead of contributing help to Upstart is: a) your personal distaste for Ubuntu and Canonical b) your personal distaste for the copyright assignment policy (RedHat have signed this agreement for Upstart fwiw) c) your personal love of nih ;-) I don't think that's a bad thing, I certainly share (c) in equal measures g. I'm also not going to argue that Fedora shouldn't chose a different init system to mine, that's not really my place to do so. However I do dispute that I haven't been flexible wrt Upstart's design; indeed I would claim that part of the reason development is slower than the rapid against-the-wall pace of other projects, is that I'm too flexible with its design ;-) Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev pgpk2nMEotNvB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010 12:42:13 +0200 drago01 drag...@gmail.com wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 12:35 +0100, Scott James Remnant wrote: We did sit down and discuss things, and you convinced me that launchd-style activation was a useful thing to have. Then you went off and wrote systemd anyway. If you want to add socket passing to upstart as well, we can turn this into a win-win situation instead of flaming each other. If both upstart systemd support this in the same way, it will will be much easier to get the patches for the various services upstream. That is great. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
* Ola Thoresen [26/05/2010 14:39] : Would it not be more fruitful to discuss _why_ you (we?) need to edit the initscripts? Describe what functionality is missing or wrong in the default ones? Editing environnement variables and indicating which specific interfaces I want the daemon to listen on for requests are the only real-world cases that come to my mind straight away. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 08:54:23AM -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010, Chuck Anderson wrote: -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. And given my experience dealing with actual real-world designed daemons and other such things, I'd say we've shown no ability to 'properly' design them and won't be showing that anytime soon. So since we have to live in the world, let's not go shooting our feet off. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010 09:08:09 -0400 (EDT) Seth Vidal skvi...@fedoraproject.org wrote: On Wed, 26 May 2010, Chuck Anderson wrote: -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. And given my experience dealing with actual real-world designed daemons and other such things, I'd say we've shown no ability to 'properly' design them and won't be showing that anytime soon. So since we have to live in the world, let's not go shooting our feet off. -sv If people are really keen on C init scripts, then a compromise could be to make it optional to use a bash script when the admin wants to do something. It would be a change and require re-training to understand how to do that, but it will be at least possible. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 02:01:35PM +0200, Tomasz Torcz wrote: On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. Precisely my point. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 14:24, Simo Sorce wrote:
On Wed, 26 May 2010 09:08:09 -0400 (EDT)
Seth Vidalskvi...@fedoraproject.org wrote:
On Wed, 26 May 2010, Chuck Anderson wrote:
-21 million.
Scripts are a crutch to avoid properly designed daemons and
configuration systems. I never edit initscripts to configure
daemons, because they would just be overwritten at the next package
upgrade. Configuration should be separate from code.
And given my experience dealing with actual real-world designed
daemons and other such things, I'd say we've shown no ability to
'properly' design them and won't be showing that anytime soon. So
since we have to live in the world, let's not go shooting our feet
off.
-sv
If people are really keen on C init scripts, then a compromise could
be to make it optional to use a bash script when the admin wants to do
something. It would be a change and require re-training to understand
how to do that, but it will be at least possible.
Simo.
I think a better compromise, if people care about speed (which is the
only reason given for using C in the first place), is to clean up the
bash code in our initscripts.
As I demonstrated in another post, you can get virtually all of the
speed of C initscripts by getting rid of basic coding errors.
For example, I have one initscript here that does:
family=`grep ^cpu family /proc/cpuinfo | head -n1 | awk -F : '{
print $2 }'`
this much slower (on this system about 3 times slower) than simply writing:
family=$(awk -F: '/^cpu family/{print $2;exit}' /proc/cpuinfo)
Unfortunately, for some reason, fixing bad bash is often perceived as
nitpicking rather than usefully contributing. Not sure why this is as
the same isn't really true of any other language.
-siXy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 9:04 AM, Chuck Anderson c...@wpi.edu wrote: On Wed, May 26, 2010 at 08:54:23AM -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. -21 million. Scripts are a crutch to avoid properly designed daemons and configuration systems. I never edit initscripts to configure daemons, because they would just be overwritten at the next package upgrade. Configuration should be separate from code. I don't edit them, but I do frequently look at them to see what they're doing/why they aren't doing something/what config files i can add/edit to change behaviour etc. actually, i do edit them sometimes to add a temporary -x to them. sure as heck beats gdb. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 14:01, Tomasz Torcz (to...@pipebreaker.pl) wrote: On Wed, May 26, 2010 at 01:26:48PM +0200, Lennart Poettering wrote: The problem we've found is that cgroups are too aggressive. They don't have a notion of sessions and count too much as being part of your service, so you end up with your screen session being counted as part of gdm. The per-user cgroups are controlled via a PAM module. That way there's finally a nice way how we can reliably clean up behind a user when he logs out: we just kill his complete cgroup and he's gone. You are avoiding the question: what about screen sessions? Whole point of screen is to stay after logout, and by killing cgroup you nullify it. Well, that depends on configuration. Many admins will probably like it if they have an easy control that allows them to enforce that a user doesn't continue running processes after he is logged out. For example, in an university network it is probably a good idea to enforce something like that on workstation machines. And in other cases (i.e. central login servier) you might want to allow screen and suchlike, i.e. processes continuing to run after the user logged out. But then, when you delete a user you still want a nice way to kill all his processes. And in both cases you still might want to enforce resources limitations on the various users. Hence grouping user processes in proper cgroups is really useful, even if you ultimately don't enable the kil user group on last logout checkbox. So, the cgroups stuff allows you to do a lot of stuff we couldn't do before. But that doesn't mean all of it is useful in all cases. In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Seth Vidal wrote: +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. Absolutely. I have no idea why you shouldn't use a small and light interpreted language rather than C. You would have a standard library of useful init related functions, so you wouldn't have to fork awk, etc. The actual init scripts would be very small then. C is also missing useful datatypes such as maps, which would require libraries to load. Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. I've had to edit an init script to get something working properly many times. Jeremy -- http://jeremysanders.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Once upon a time, drago01 drag...@gmail.com said: This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. But they aren't a major slowdown factor (see the example numbers in this thread). And, if they were, any init scripts that are a problem could probably be optimized and still be shell scripts (a number of sed/awk/grep calls could probably be rewritten as pure bash for example). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. This is a nice example of how discussions on this list go off into the weeds in no time. 'compiling initscripts' ? come on, that is just silly. Nobody is proposing such a thing. It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26 May 2010, Matthias Clasen wrote: On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. This is a nice example of how discussions on this list go off into the weeds in no time. 'compiling initscripts' ? come on, that is just silly. Nobody is proposing such a thing. It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. great - then I'm happy to be mistaken. thanks for clearing it up. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 4:07 PM, Jeremy Sanders jer...@jeremysanders.net wrote: Seth Vidal wrote: +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. Absolutely. I have no idea why you shouldn't use a small and light interpreted language rather than C. You would have a standard library of useful init related functions, so you wouldn't have to fork awk, etc. The actual init scripts would be very small then. C is also missing useful datatypes such as maps, which would require libraries to load. Something like Lua would be very good. The overheads over C would be minimal, and it would have the advantage of being editable. Well spawing your logic further means we should avoid compiled programs at all, what if I want configure $app by editing its source code? Oh wait it is written in C ... If it goes down to want to edit scripts for configuration reasons (which isn't sane anyway) compared to a faster an cleaner boot process I'd opt for the later. Seriously source code is NOT and never was intended to be a configuration system period. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 4:16 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, drago01 drag...@gmail.com said: This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. But they aren't a major slowdown factor (see the example numbers in this thread). They are flawed, simply spawning awk multiple times and measure the time is not a test to compare bash to C. And, if they were, any init scripts that are a problem could probably be optimized and still be shell scripts (a number of sed/awk/grep calls could probably be rewritten as pure bash for example). Which would be faster than spawing random process but still orders of magnitudes slower than a C program. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Once upon a time, drago01 drag...@gmail.com said: On Wed, May 26, 2010 at 4:16 PM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, drago01 drag...@gmail.com said: This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. But they aren't a major slowdown factor (see the example numbers in this thread). They are flawed, simply spawning awk multiple times and measure the time is not a test to compare bash to C. And, if they were, any init scripts that are a problem could probably be optimized and still be shell scripts (a number of sed/awk/grep calls could probably be rewritten as pure bash for example). Which would be faster than spawing random process but still orders of magnitudes slower than a C program. Where are your numbers proving this is a measurable impact? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 26/05/10 15:20, Matthias Clasen wrote: On Wed, 2010-05-26 at 08:54 -0400, Seth Vidal wrote: On Wed, 26 May 2010, Simo Sorce wrote: While you don't edit them *all* the time, it is something that is done regularly, and it is something most admins can do with ease. Turn them in a C program and you left admins out in the cold, most of them. I would be very, very wary of accepting a C init script. An unmanageable system is a useless system. +20 million. I couldn't agree more. They need to be scripts, considering how seldom they actually run it makes even less sense to chase down optimization in them by making them compiled. This is a nice example of how discussions on this list go off into the weeds in no time. 'compiling initscripts' ? come on, that is just silly. Nobody is proposing such a thing. It is completely clear that there needs to be some flexibility in any init system to cater to real-world services. But it is also clear that there is a difference between gobs of shell script and nice and clean files like the ones you find in /etc/init. Actually the blog post is proposing exactly that, as I read it. And it seems not only that lots of other people read it the same way, but some even agree with it. So I'm not sure I see how this is going off into the weeds - if transitioning some/all initscripts to C is a genuine goal of the author of the project, on which he is not prepared to budge, then that is likely to have bearing on its adoption into fedora, and rightly so. -siXy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 08:43 -0400, Matthias Clasen wrote: On Wed, 2010-05-26 at 12:35 +0100, Scott James Remnant wrote: We did sit down and discuss things, and you convinced me that launchd-style activation was a useful thing to have. Then you went off and wrote systemd anyway. If you want to add socket passing to upstart as well, we can turn this into a win-win situation instead of flaming each other. If both upstart systemd support this in the same way, it will will be much easier to get the patches for the various services upstream. That is great. I don't see any reason not to at least pass the LISTEN_FDS environment variable (though I can't figure out what LISTEN_PID is for?) Upstart will support a different mechanism as well though, because for the services we want to activate this way in Ubuntu, there are benefits to having the services phone back to Upstart to pick up the socket. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Adam Williamson wrote: I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? What about a compromise? The initscripts are plain text files that get compiled after you edit them. Solution 1 Example: viinit postgresql Make your changes :wq viinit compiles your script into a binary. Solution 2: Give Bash JIT. OTOH, why is this even a sub-topic in this sub-topic of a thread? I'd love to see some numbers from the complainers about scripting being slow. I have a normal Fedora 13 x86_64 system that boots through initscripts in under 10 seconds. Normal services are starting as I have not tweaked my service list. Unless Fedora needs a 1 second boot time (hey I wouldn't complain) do we really need to spend time on 100+ email threads and jump through multiple init systems to find that perfect solution? I've read similar claims of salvation when upstart was being marketed to replace SysVinit. Everyone will switch to native scripts and everything will be better! Has everyone switched to native upstart scripts? AFAIK - No. Will everyone switch to systemd native scripts? I'm betting - no. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 10:01, James Findley (s...@gmx.com) wrote:
3) Cutting down on the forking by replacing some of the shell scripts...
cool
3a) With C code... really?
Yeah. I think this is odd too.
The blog complains about how many awk spawns there are - but this looks
like a complaint that belongs in the 70's.
It really doesn't take long to launch awk. at all. And most of the
things people are asking awk to do in shell scripts are very trivial,
requiring very little processing.
Maybe individually its not a problem. But doing that all the time ( 1000x
or so during boot) is just slow.
using a simple for i in {1..1000}; do ... loop I can launch on this
rubbish old laptop a thousand awk processes in 3.35 seconds. By
It's no only about launching it. Take a couple of tools, pipe them
together, and actually execute some code with it.
comparison, it takes 2.24 seconds to launch a thousand C hello world
programs. So C is faster. Just about. But the complaint in the blog
is that awk is called 92 times. By this metric that costs the user 0.3
seconds of CPU time. To get rid of this horrible waste of resources we
are compiling all our startup scripts wait. Something is wrong with
that picture ;)
Dude, this is not what I am suggesting, I want no compiled startup
scripts.
All I am saying that the majority of stuff should just be done in the
init system or the daemons themselves. And if there is something to
configure then do so in the .service file or in the daemon
configuration. But there is no point in keeping all in shell.
Also 2.24s is already quite a bit, if I may say so.
Modern systems just don't take very long to spawn awk. Or sed. Or cut.
Or bash. IMO this sort of tradeoff between speed and ease of use hasn't
been appropriate in 20 years.
Well, they actually do if you do that a thousand times.
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
We are not taking control away from you: you can still configure the
.service file to your needs, and you have much more high-level controls
in there, and if you really want to you can still plug in a shell script
instead of the daemon binary itself and things will work just fine.
Also, much the code in the init scripts simply goes away without any
need for replacement if the init system is just smarter. You will have
to debug less, you will have to fix less, because there is less code,
and less buggy code, and less fragile shell code. You also will have
less duplication in each and every init script.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 6:07 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. Again the sysadmin case just implies that something *else* is broken. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. Why don't people try to configure lets say X by editing its code'? Does this sound wrong to you? If yes than why would initscripts be different? If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C Well if you want to write and modify something you have to know the language it is written in, in case you don't it isn't a problem either just ask for help. It is not rocket science or something that would required hundreds of man hours. What about people who write apps that need initscripts in some other language? See above. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 26.05.10 12:27, seth vidal (skvi...@fedoraproject.org) wrote: Right, would be good if you could elaborate about that. I alead asked you a couple of times about this. Would love to hear about the reasoning. Scott, Lennart, A Proposal: maybe the two of you should continue this discussion off-list, in private. Well, just to point out, Scott and I and Kay had a private email exchange just about this yesterday and the day before yesterday. Was kinda one-sided, the public discussion is sometimes helpful to actually force those involved to make real points, instead of wishy-washy comments... But anyway, I see no point on continuing that here either. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
I've made some benchmarks starting a dummy service (do not call any programs
or kill) and a samba server on my notebook. I run those tests 4 times and
discarded the first one. Each test execute 100 times the command:
service dummy restart = 0,023ms
service smb restart = 0,158ms
c application = 0,016ms
After I made this change:
--- /etc/init.d/functions2010-05-26 13:26:00.0 -0300
+++ /etc/init.d/functions2010-05-26 13:03:01.0 -0300
@@ -305,12 +305,13 @@
if checkpid $pid 21; then
# TERM first, then KILL if not dead
kill -TERM $pid /dev/null 21
- usleep 10
- if checkpid $pid sleep 1
+ usleep 1000
+ if checkpid $pid usleep 10
+ checkpid $pid sleep 1
checkpid $pid sleep $delay
checkpid $pid ; then
kill -KILL $pid /dev/null 21
-usleep 10
+usleep 5
fi
fi
checkpid $pid
After this, the time dropped 60%:
service smb restart = 0,051ms
And finally I wrote this C application:
#include unistd.h
#include stdlib.h
#include sys/wait.h
int main(int argc,char *argv[]) {
int pid,ret,a;
for(a=0;a100;a++) {
if((pid=fork())==0) {
execlp(smbd,smbd,-D,NULL);
exit(-1);
}
waitpid(pid,ret,0);
kill(pid,9);
}
exit(0);
}
This is the final result:
service dummy restart = 0,023ms
service smb restart = 0,158ms
service smb restart (after hack) = 0,051ms
c application = 0,016ms
We are talking about to gain 0.035ms per process on init using C (service
restart) in my notebook.
Gustavo Junior Alves
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 06:39:43PM +0200, drago01 wrote: Again the sysadmin case just implies that something *else* is broken. Sure. As a distribution, we don't have control over upstream projects and their assumptions for daemon startup, shutdown, status, etc. Sometimes, they want odd things. Well if changing over to C does only get rid of this disease it would be enough of a gain. It would force broken apps to be fixed, and let admins edit *configuration* files and not source code. If you think you can get every open source / free software project to agree on completely consistent behavior, or if you can create a text-format config file for your compiled daemon handler which handles every unanticipated case, well, okay. But it seems unlikely. (And that's not even considering running non-free software, which, while something I try to avoid, is a reasonable real-world use.) Why don't people try to configure lets say X by editing its code'? X is one program produced by one project, with a text-mode config file that handles all of its possible options. That's easy. Does this sound wrong to you? If yes than why would initscripts be different? Because the initscripts system needs to flexibly handle and make pretty any random mess thrown at it. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering mzerq...@0pointer.de wrote: http://0pointer.de/public/dbus.service. Note the ExecStartPre here, like most daemons, is conceptually busted. There's no reason we shouldn't lay that file down once when the OS is installed, and not check it every boot. Or alternatively, just move the uuid generation into the daemon itself. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 5:55 AM, Lennart Poettering mzerq...@0pointer.de wrote: Well, that depends on configuration. In systemd you can choose individually for each unit whether you want to allow it to continue run processes on shut down, whether you want the main process killed, the process group to be killed or the cgroup to be killed. Do you have a service file example yet in systemd git that can be used to get an understanding of the various configuration options which determine what gets killed and what doesn't? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, 2010-05-26 at 18:14 +0200, Lennart Poettering wrote: Oh come on. Thanks for turning this into something personal. You did that last week - I got forwarded logs from #systemd. That's probably why I wasn't in a great mood with you this morning ;-) I'd prefer it we would keep this discussion purely technical. Everything else does not help at all in this matter. I think you're wrong, you think I'm wrong; let's go shopping :-) I only jumped in to refute your comment that you'd talked to me, and I hadn't listened, because that was incorrect. I'm not sure there's any point in technical discussion about the relative merits of our two approaches at this point, since you've already *written* systemd and you're already pushing for inclusion in distributions, and I'm continuing to develop Upstart and already have it in distributions. So what we've ended up with is two different systems, and one can assume that roughly half the distributions will end up with one, and another half with the other. At least we have the common standard of the LSB Init Scripts that both will support. Scott -- Scott James Remnant sc...@canonical.com signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On Wed, May 26, 2010 at 12:50 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Wed, 26.05.10 09:07, Adam Williamson (awill...@redhat.com) wrote: On Wed, 2010-05-26 at 12:42 +0200, drago01 wrote: On Wed, May 26, 2010 at 5:02 AM, Casey Dahlin cdah...@redhat.com wrote: On Tue, May 25, 2010 at 05:45:07PM +0200, Lennart Poettering wrote: On Tue, 25.05.10 10:21, Casey Dahlin (cdah...@redhat.com) wrote: [...] 3) Cutting down on the forking by replacing some of the shell scripts... cool 3a) With C code... really? This does make a lot of sense to me, initscripts being scripts is a major slowdown factor by itself. It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? THERE ARE NO PLANS TO SHIP COMPILED INIT SCRIPTS OR ANYTHING LIKE THAT! The plan is to reduce what is currenlty done in files like /etc/init.d/messagebus to files like http://0pointer.de/public/dbus.service. Also: Description=D-Bus System Bus This seems unnecessary. Can we default to the name of the script? If this isn't translated, I don't see how it's more interesting than just dbus. Requires=basic.target sockets.target dbus.socket After=basic.target sockets.target dbus.socket What does this goop mean and why is it necessary? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
On 05/26/2010 12:07 PM, Adam Williamson wrote: It is not like you want to edit the scripts all the time, so there is no reason for them being scripts. I beg to differ. I've had to create or modify initscripts quite often, either as a sysadmin or a packager. If this is now going to require C coding skills, I'm not going to be able to do it. I don't think it's safe to assume that everyone who needs to write or modify an initscript is going to know C. What about people who write apps that need initscripts in some other language? It could work out if systemd provided access to a system() equivalent which could then execute an arbitrary script. I think one good argument for redoing initscripts is that they are so repetitive: most of the content is fairly standard: initialization, argument parsing, case $1 in start) stop), etc etc. ; stuff that might as well be done in the common framework. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
ons 2010-05-26 klockan 10:01 +0100 skrev James Findley:
It's really not at all uncommon for me to need to modify an init script.
There would be much rage if in order to do this I had to download the
SRPM, extract the init code, figure out what I needed to change, modify
it, recompile then install.
Various ways to deal with that:
1. Change the Exec=/usr/libexec/food to
ExecStart=/usr/local/sbin/foodwrapper
2. Add some hook support in the systemd config files.
3. Add support for switching specific services back to using the
initscript even when booting with systemd.
But on the other hand, shell scripts can be optimised too. Maybe the awk
call is redundant anyway? Maybe something like foo=${bar%.conf} would
be enough?
/Alexander
PS.
Someday I should go on a rampage and submit patches that add set -e;
set -o pipefail to the start of every shell script in the distro. Or
maybe not...
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd (Was Re: tmpfs for strategic directories)
Le dimanche 23 mai 2010 à 00:34 +0200, Lennart Poettering a écrit : ATM everything looks rosy. I just finished porting over all F13 installed-by-default daemons to socket activation, and a few more (and the patches are good enough to be upstreamable). For this kind of stuff I strongly suggest you do not limit yourself to F13 installed-by-default daemons (which are mostly well-behaved C/C++ desktop-oriented code) but pass the reality check of converting important server daemons (postfix, apache, bind...) and non C/C++ services (jboss or tomcat in java, amavisd-new or something else in perl, etc) Otherwise you'll replay the networkmanager drama with part of the Fedora users going the new laptop way, part refusing to even look at it because it can not translate in the server stuff they need at work, and everyone being very sad, unhappy, and angry at others. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
