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?
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
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
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
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 Poettering - Red Hat, Inc.