On Tue, 24.08.10 16:38, Bill Nottingham (notting@xxxxxxxxxx) wrote: > > Lennart Poettering (mzerqung@xxxxxxxxxxx) said: > > > - init shall support a mechanism to re-exec itself to not cause dirty > > > inodes on shutdown; initscripts will use this method on shutdown. > > > > This is bad. While we support this just fine I think it is a really bad > > idea to reexec init at shutdown. What's the point of this, can you elaborate on > > this? This smells to me as a workaround for brokeness in older init > > systems, and I don't see a reason why reexecing itself would be > > necessary for systemd. > > If the libraries or binaries used by systemd are replaced during runtime, > and it is not re-executed on shutdown, the filesystem will have busy inodes > on shutdown. (If you'd like to take the filesystem semantics up with the > kernel, feel free to tilt at that windmill.) Hmm, so this is about files that are deleted but still mapped by init, and which can only be deleted when init stops referencing them, but that is required to remount the fs r/o? Did I get this right? I am not really convinced that reexecing is the right answer for this problem. But well, since this already works anyway I guess this doesn't really matter too much. > That's why it's optional... given that we don't do this now, it can be > dropped. (You'd be amazed at the number of bug reports we've gotten from > people who *think* we do this now, and are confused when it doesn't > happen.) I think we'd be ill advised to support this ever. We should take input only from whatever /dev/console refers to (and input on /dev/console only comes from the main console). Everything else I think is dangerous. > > > PACKAGING > > > - Guidelines for packaging systemd units shall be formalized. > > > > As pointed out elsewhere, I'd avoid this for F14. > > Then we should put "don't" in the guidelines, instead. We need to set clear > expectations for package maintainers as to what they should be doing. (And > certainly not switching the state of their packages mid-release.) Well, if we can agree on "don't, unless you contacted Lennart or [add list here] and he said it's OK" then I am fine with this. > > > ORDERING > > > - rc.local will run as the final service on bootup. > > > - gettys will not start until after rc.local. > > > - prefdm will start coincident to gettys (earlier?) > > > > Well, first of all, the first two items here obviously contradict. But > > putting that aside: I don't think speaking of ordering here these days > > really makes sense. Neither was it traditionally run as last thing of > > bootup (i.e. it was only synchronized against sysv scripts, not against > > upstart, inittab, dbus, cron, inetd services) > > Correct, it was synchronized against SysV scripts. And, IMO, it should > stay that way. Principle of least surprise. If you want that reworded > as 'the final SysV service', that's not an issue. Well, if we can agree on "after all sysv services that include no proper ordering dependency information in the LSB headers", then I'd be fine with this. If sysv services contain LSB headers, we should follow the ordering it encodes, not come with implicit additional rules. > OK, so now you've stated 5 times in this mail some equivalent of > 'that's not my package, it shouldn't be my problem, I don't want to be > responsible for this.' > > I'm going to be blunt. I DON'T CARE. Yay, thanks that you don't care. You are aware that by putting everything on a single man's shoulders and then telling him "you don't care" you make him feel really welcome and make him wonder why he even bothers with this shit? > Sure, I suppose individual maintainers want to push their code over the wall and > then sit in their silo and claim 'that's not my problem' and 'someone else > needs to fix that', well, that's their right to be lame. But we, as Fedora, > as producers of a product that we ship to our users, don't have that luxury. But you enable them to block out change. For example, if somebody refuses to merge a patch that adds a systemd equivalent for an upstart config hook he has, he can sink the whole systemd in fedora project. I am pretty sure some folks would be really happy to have that power... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
