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.) > Also, let's not forget that this requirement didn't exist for > Upstart. Upstart always has been and still is unable to reexec itself. upstart doens't support re-execution while maintaining internal state. It *does* support minimal re-execution for this usage. > > - (optional) Booting with secondary serial consoles does the same. > > Hmm, could you elaborate on this? We have discussed this a couple of > times upstream, and came to the conclusion that the only safe thing to > do is to run a getty only on the main kernel console, i.e. where input > is accepted from. 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.) > > 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.) > > SERVICE HANDLING > > - Running 'chkconfig <foo> <(null)|on|off>' on a service managed by systemd > > will return the correct code/perform an appropriate action. > > Hmpff. I don't think this is a good idea. chkconfig should manage SysV > scripts, and "systemctl enable" should manage systemd units. But > interpolating this would create the impression the semantics were > identical, although they really aren't. > > What would make sense to add to chkconfig is something that checks > whether a systemd unit is installed and then prints "Hey, you have a > systemd unit installed, chkconfig won't do what you think it will do for > this unit" or so. This isn't good enough, IMO. chkconfig is a utility used by admins, scripts, and packages in an automated fashion. Breaking their scripts is something that should not be taken lightly. Making every script or utility that an admin has have to have code for checking with chkconfig, and checking with systemd, all in the same release, is pretty rude. > > 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. > really. But I am not even too convinced about the prefdm/getty ordering, > as this creates an unnecessary synchronization point for everybody, even > though rc.local is empty (which it probably is for 99.9% of all > people). So, if the admin happens to add something to rc.local that needs synchronization, instead of it working as it has been, he has to rejigger the unit configuration? Ick. > We want prefdm to start as early as possible. That is a separate discussion that should be had once we have the basic functionality verified and working, IMO. If we want to reorganize around early login, we should do that as a coordinated effort in F-15, not as an ad-hoc side-effect of the systemd configuration. > > -- iSCSI / > > -- LDAP user information > > -- IPA/AD user information > > -- NIS user information > > Can't test any of this really. Wouldn't even know how to test this. I also > don't want to be responsible for the fact taht nss-ldap is borked. 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. It's about the integration into the system. Playing a blame game doesn't help... if the system doesn't work, we can't ship that way. If there are enough blockers in other packages that prevent a systemd system from functioning to these sorts of specifications, we cannot ship systemd. Period. The onus is on the introducer of a large change to make sure that change works in the system. Sure, we can fire up requests for help, we can lean on people to fix their packages, and we've got people who are willing to help. 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. Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
