On Tue, 2010-08-24 at 23:31 +0200, Lennart Poettering wrote:
On Tue, 24.08.10 16:38, Bill Nottingham (notting(a)redhat.com) wrote:
> Lennart Poettering (mzerqung(a)0pointer.de) 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