On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote: > 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? Yes, that's 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. Indeed, it's a hack, but there's no better option in sight, so I don't see the point in complaining. > > 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. If that happens, take it to FESCo. -- Matt -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
