Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Tue, 25.03.14 19:07, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-25 0:14 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 23:59, Michael Biebl (mbi...@gmail.com) wrote: I think the priority information is irrelevant in this particular issue. It's the discrepancy regarding runlevel information. So I doubt your patch makes a difference, but I'll double check. I am tempted to also drop the runlevel parsing from the LSB and chkconfig headers. After all they are mostly irrelevant since what is linked in /etc/rc?.d/ is what matters, and not the stuff in the init script themselves. Let me now if this would make things work then for you. If so, I'll drop this too then. I think this might work, without having actually tested it. That said, if you drop runlevel and priority parsing from the chkconfig header, is there anything useful left in # chkconfig: ? Nope, there wouldn't be. Regarding # pidfile:, it's basically the same problem, ie. the mere existence (on Debian) doesn't necessarily mean it is correct. The result could be, that we mark a service as Type=forking pointing it at the wrong pid file, leading to the service not being tracked properly. I'd have to check all packages affected by this [0], to see if the information in there is actually correct. [0] http://codesearch.debian.net/search?q=%23+pidfile%3A I am pretty sure that this is something to fix in the init scripts rather than to drop entirely. the pidfile option is simply increadibly useful. I have now added a todo list item to drop chkconfig parsing entirely. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
Le lundi 24 mars 2014 à 19:24 +0100, Lennart Poettering a écrit : On Mon, 24.03.14 19:20, Frederic Crozat (fcro...@suse.com) wrote: Le lundi 24 mars 2014 à 18:58 +0100, Lennart Poettering a écrit : It's simply that the PID file info in the chkconfig header is just increadibly useful (since it allows us to identify the main process of a service) and I'd really like to make sure we make use of it wherever possible. So that chkconfig header bit is what I am interested in, not the priority number... I must confess I stole the PID file info part and added it in the LSB header parsing, because we sometime have initscripts which such informations (which is good) and we also sometime would like to have this information handy, despite the fact we use LSB headers (and not Fedora ones).. I can't and won't make you stop doing this, but let me just say that I really don't like that you do this, and that this is something I would never merge upstream: We really don't want to extend old standards with private systemd extensions, if we consider those old standards obsolete anyway. If people want to use systemd features they should use systemd files. Compatibility we do for the sake of compatibility only, not do extend standards we consider deeply flawed, and that we'd prfer if they went away sooner rather than later. Unfortunately, reality not always mixes well with such principles. You are fortunate to have support for this particular header in your flavor of initscripts and we aren't. And there has some particular times where we need this information and we can't just replace initscripts with a service counterpart (specially when you find issues during maintenance update). I'll be happy when we are able to drop those changes (or move them to generator) but we aren't there yet. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-25 0:14 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 23:59, Michael Biebl (mbi...@gmail.com) wrote: I think the priority information is irrelevant in this particular issue. It's the discrepancy regarding runlevel information. So I doubt your patch makes a difference, but I'll double check. I am tempted to also drop the runlevel parsing from the LSB and chkconfig headers. After all they are mostly irrelevant since what is linked in /etc/rc?.d/ is what matters, and not the stuff in the init script themselves. Let me now if this would make things work then for you. If so, I'll drop this too then. I think this might work, without having actually tested it. That said, if you drop runlevel and priority parsing from the chkconfig header, is there anything useful left in # chkconfig: ? Regarding # pidfile:, it's basically the same problem, ie. the mere existence (on Debian) doesn't necessarily mean it is correct. The result could be, that we mark a service as Type=forking pointing it at the wrong pid file, leading to the service not being tracked properly. I'd have to check all packages affected by this [0], to see if the information in there is actually correct. [0] http://codesearch.debian.net/search?q=%23+pidfile%3A -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 14:00, Michael Biebl (mbi...@gmail.com) wrote: Don't parse Red Hat style chkconfig headers if chkconfig support is disabled via --disable-chkconfig. Hmm, I am not overly hapy with adding even more ifdefs to the code... i'd rather see less ifdefs... Thus, what's the rationale here? Why shouldn't the chkconfig header be read when it exists? I mean, stuff like the description string really shouldn't hurt on debian either, should an init script carry the header... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 17:11 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 14:00, Michael Biebl (mbi...@gmail.com) wrote: Don't parse Red Hat style chkconfig headers if chkconfig support is disabled via --disable-chkconfig. Hmm, I am not overly hapy with adding even more ifdefs to the code... i'd rather see less ifdefs... Thus, what's the rationale here? Why shouldn't the chkconfig header be read when it exists? I mean, stuff like the description string really shouldn't hurt on debian either, should an init script carry the header... Lennart -- Lennart Poettering, Red Hat -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 17:11 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 14:00, Michael Biebl (mbi...@gmail.com) wrote: Don't parse Red Hat style chkconfig headers if chkconfig support is disabled via --disable-chkconfig. Hmm, I am not overly hapy with adding even more ifdefs to the code... i'd rather see less ifdefs... I can rip out the chkconfig parsing completely, if that is what you want. Thus, what's the rationale here? Why shouldn't the chkconfig header be read when it exists? I mean, stuff like the description string really shouldn't hurt on debian either, should an init script carry the header... The reasoning here is, that on distributions which don't use chkconfig (like Debian), there might be SysV init scripts with chkconfig headers which are completely untested and actually break the boot process. See [0] for an example. We really shouldn't parse chkconfig headers on distros which don't support chkconfig and decided to build systemd with --disable-chkconfig. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634472#47 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 17:17, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-24 17:11 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 14:00, Michael Biebl (mbi...@gmail.com) wrote: Don't parse Red Hat style chkconfig headers if chkconfig support is disabled via --disable-chkconfig. Hmm, I am not overly hapy with adding even more ifdefs to the code... i'd rather see less ifdefs... I can rip out the chkconfig parsing completely, if that is what you want. Nah, we need to keep it in for fedora/rhel I figure, for now. Thus, what's the rationale here? Why shouldn't the chkconfig header be read when it exists? I mean, stuff like the description string really shouldn't hurt on debian either, should an init script carry the header... The reasoning here is, that on distributions which don't use chkconfig (like Debian), there might be SysV init scripts with chkconfig headers which are completely untested and actually break the boot process. See [0] for an example. We really shouldn't parse chkconfig headers on distros which don't support chkconfig and decided to build systemd with --disable-chkconfig. Well, but we are a lot more dependent on correct headers than other parsers anyway... For example, the LSB deps have traditionally been much less accurately followed than they are now... I mean, we don't claim compatibility with scripts with broken headers, anyway... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 17:21 GMT+01:00 Lennart Poettering lenn...@poettering.net: Well, but we are a lot more dependent on correct headers than other parsers anyway... For example, the LSB deps have traditionally been much less accurately followed than they are now... I mean, we don't claim compatibility with scripts with broken headers, anyway... Sorry, but I don't get your point. If I disable chkconfig support, then I don't want the chkconfig headers parsed. Isn't that quite obvious? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 17:25, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-24 17:21 GMT+01:00 Lennart Poettering lenn...@poettering.net: Well, but we are a lot more dependent on correct headers than other parsers anyway... For example, the LSB deps have traditionally been much less accurately followed than they are now... I mean, we don't claim compatibility with scripts with broken headers, anyway... Sorry, but I don't get your point. If I disable chkconfig support, then I don't want the chkconfig headers parsed. Isn't that quite obvious? Well, it's two different things: a) defer to /sbin/chkconfig if systemctl enable is used on a sysv service. b) take into account any information included in the sysv header that exists. Turning off chkconfig support does a), not b). And I'd really prefer if sysv scripts would behave the same way on all systemd installations... I mean that's what we try to do after all, provide a unified interface for developers... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 17:21 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 17:17, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-24 17:11 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 14:00, Michael Biebl (mbi...@gmail.com) wrote: Don't parse Red Hat style chkconfig headers if chkconfig support is disabled via --disable-chkconfig. Hmm, I am not overly hapy with adding even more ifdefs to the code... i'd rather see less ifdefs... I can rip out the chkconfig parsing completely, if that is what you want. Nah, we need to keep it in for fedora/rhel I figure, for now. So you're saying as long as it benefits Fedora, having ifdefs is fine, but not for other distros? Thus, what's the rationale here? Why shouldn't the chkconfig header be read when it exists? I mean, stuff like the description string really shouldn't hurt on debian either, should an init script carry the header... The reasoning here is, that on distributions which don't use chkconfig (like Debian), there might be SysV init scripts with chkconfig headers which are completely untested and actually break the boot process. See [0] for an example. We really shouldn't parse chkconfig headers on distros which don't support chkconfig and decided to build systemd with --disable-chkconfig. Well, but we are a lot more dependent on correct headers than other parsers anyway... we = Fedora? Don't quite get your point in this context. For example, the LSB deps have traditionally been much less accurately followed than they are now... Regarding Debian, the LSB headers are the only ones which are actually tested and accurate. If there are chkconfig headers in the init scripts there are most likely leftovers and are completely untested. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 17:36 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 17:25, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-24 17:21 GMT+01:00 Lennart Poettering lenn...@poettering.net: Well, but we are a lot more dependent on correct headers than other parsers anyway... For example, the LSB deps have traditionally been much less accurately followed than they are now... I mean, we don't claim compatibility with scripts with broken headers, anyway... Sorry, but I don't get your point. If I disable chkconfig support, then I don't want the chkconfig headers parsed. Isn't that quite obvious? Well, it's two different things: a) defer to /sbin/chkconfig if systemctl enable is used on a sysv service. b) take into account any information included in the sysv header that exists. Turning off chkconfig support does a), not b). And I'd really prefer if sysv scripts would behave the same way on all systemd installations... I mean that's what we try to do after all, provide a unified interface for developers... Since Debian doesn't have chkconfig, sysv init script already behave differently when it comes to a), so the point about having sysv init scripts behave the same on all systemd installations is moot. It really doesn't make sense to parse the chkconfig headers on distros which don't support that interface. The result is worse then not parsing it at all. I don't mint terribly if you want to keep the # description: parsing in, but the # chkconfig: and # pidfile: parsing should not be done on distros where does headers never have been used/tested. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 17:37, Michael Biebl (mbi...@gmail.com) wrote: Hmm, I am not overly hapy with adding even more ifdefs to the code... i'd rather see less ifdefs... I can rip out the chkconfig parsing completely, if that is what you want. Nah, we need to keep it in for fedora/rhel I figure, for now. So you're saying as long as it benefits Fedora, having ifdefs is fine, but not for other distros? No. I mentioned before that I'd be happy to add code that defers to update-rcd on Debian, instead of chkconfig. No problem with that. If Debian has worthwile header extensions I'd parse them too, if they are Okish to support. It's really not about Debian vs. Fedora. The sysv support really should be removed from PID 1 anyway, and be placed in a generator, so that the legacy stuff doesn't pollute PID 1 anymore... But I never found the time to do that... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 17:46 GMT+01:00 Michael Biebl mbi...@gmail.com: sysv scripts would behave the same way on all systemd installations... I mean that's what we try to do after all, provide a unified interface for developers... Since Debian doesn't have chkconfig, sysv init script already behave differently when it comes to a), so the point about having sysv init scripts behave the same on all systemd installations is moot. It also needs to be pointed out that SysV init scripts are unfortunately anything but distribution agnostic. Be it the location, return codes, shell libraries used etc. So saying that a given SysV init script should work and behave consistent on all systemd installations is simple an unrealistic expectation. The legacy SysV support should rather try to make the *existing* SysV init scripts run as smoothly as possible. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 17:46, Michael Biebl (mbi...@gmail.com) wrote: Turning off chkconfig support does a), not b). And I'd really prefer if sysv scripts would behave the same way on all systemd installations... I mean that's what we try to do after all, provide a unified interface for developers... Since Debian doesn't have chkconfig, sysv init script already behave differently when it comes to a), so the point about having sysv init scripts behave the same on all systemd installations is moot. Well, but that's a difference in install time behaviour, not runtime behaviour... It really doesn't make sense to parse the chkconfig headers on distros which don't support that interface. The result is worse then not parsing it at all. I don't mint terribly if you want to keep the # description: parsing in, but the # chkconfig: and # pidfile: parsing should not be done on distros where does headers never have been used/tested. So, what about this: what actually breaks for you? the runlevel info or the priority info? Or something else from the chkconfig header? We could probably just drop the priority info parsing entirely, since it is pretty useless these days: as no native units carry a priority number we cannot make any useful use of the chkconfig priority anyway anymore... It is only useful to order sysv scripts with such a number against other sysv scripts with such a number, but not against any other service... Hence, given it is broken/useless already, if we drop that specific part of chkconfig support entirely, would that be enough for your issue as well? It's simply that the PID file info in the chkconfig header is just increadibly useful (since it allows us to identify the main process of a service) and I'd really like to make sure we make use of it wherever possible. So that chkconfig header bit is what I am interested in, not the priority number... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 19:20, Frederic Crozat (fcro...@suse.com) wrote: Le lundi 24 mars 2014 à 18:58 +0100, Lennart Poettering a écrit : It's simply that the PID file info in the chkconfig header is just increadibly useful (since it allows us to identify the main process of a service) and I'd really like to make sure we make use of it wherever possible. So that chkconfig header bit is what I am interested in, not the priority number... I must confess I stole the PID file info part and added it in the LSB header parsing, because we sometime have initscripts which such informations (which is good) and we also sometime would like to have this information handy, despite the fact we use LSB headers (and not Fedora ones).. I can't and won't make you stop doing this, but let me just say that I really don't like that you do this, and that this is something I would never merge upstream: We really don't want to extend old standards with private systemd extensions, if we consider those old standards obsolete anyway. If people want to use systemd features they should use systemd files. Compatibility we do for the sake of compatibility only, not do extend standards we consider deeply flawed, and that we'd prfer if they went away sooner rather than later. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
Le lundi 24 mars 2014 à 18:58 +0100, Lennart Poettering a écrit : It's simply that the PID file info in the chkconfig header is just increadibly useful (since it allows us to identify the main process of a service) and I'd really like to make sure we make use of it wherever possible. So that chkconfig header bit is what I am interested in, not the priority number... I must confess I stole the PID file info part and added it in the LSB header parsing, because we sometime have initscripts which such informations (which is good) and we also sometime would like to have this information handy, despite the fact we use LSB headers (and not Fedora ones).. -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 19:04, Michael Biebl (mbi...@gmail.com) wrote: We could probably just drop the priority info parsing entirely, since it is pretty useless these days: as no native units carry a priority number we cannot make any useful use of the chkconfig priority anyway anymore... It is only useful to order sysv scripts with such a number against other sysv scripts with such a number, but not against any other service... Hence, given it is broken/useless already, if we drop that specific part of chkconfig support entirely, would that be enough for your issue as well? See the bug report I posted earlier. The discrepancy between the chkconfig head and the LSB header (the latter being the correct one) caused a dependency loop and ultimately dbus.socket to be dropped. So this is about the priority number and nothing else? If so, then I am happy to take a patch that drops taking the chkconfig priority number into account entirely, while leaving the rest of chkconfig parsing in there, unconditionally. That should fix the immediate bug you are encountering, right? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
We could probably just drop the priority info parsing entirely, since it is pretty useless these days: as no native units carry a priority number we cannot make any useful use of the chkconfig priority anyway anymore... It is only useful to order sysv scripts with such a number against other sysv scripts with such a number, but not against any other service... Hence, given it is broken/useless already, if we drop that specific part of chkconfig support entirely, would that be enough for your issue as well? See the bug report I posted earlier. The discrepancy between the chkconfig head and the LSB header (the latter being the correct one) caused a dependency loop and ultimately dbus.socket to be dropped. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 19:21, Lennart Poettering (lenn...@poettering.net) wrote: See the bug report I posted earlier. The discrepancy between the chkconfig head and the LSB header (the latter being the correct one) caused a dependency loop and ultimately dbus.socket to be dropped. So this is about the priority number and nothing else? If so, then I am happy to take a patch that drops taking the chkconfig priority number into account entirely, while leaving the rest of chkconfig parsing in there, unconditionally. That should fix the immediate bug you are encountering, right? I have commited such a change now. Can you verify if this improves things for you? Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
2014-03-24 19:58 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 19:21, Lennart Poettering (lenn...@poettering.net) wrote: See the bug report I posted earlier. The discrepancy between the chkconfig head and the LSB header (the latter being the correct one) caused a dependency loop and ultimately dbus.socket to be dropped. So this is about the priority number and nothing else? If so, then I am happy to take a patch that drops taking the chkconfig priority number into account entirely, while leaving the rest of chkconfig parsing in there, unconditionally. That should fix the immediate bug you are encountering, right? I have commited such a change now. Can you verify if this improves things for you? I think the priority information is irrelevant in this particular issue. It's the discrepancy regarding runlevel information. So I doubt your patch makes a difference, but I'll double check. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: make parsing of chkconfig headers conditional
On Mon, 24.03.14 23:59, Michael Biebl (mbi...@gmail.com) wrote: 2014-03-24 19:58 GMT+01:00 Lennart Poettering lenn...@poettering.net: On Mon, 24.03.14 19:21, Lennart Poettering (lenn...@poettering.net) wrote: See the bug report I posted earlier. The discrepancy between the chkconfig head and the LSB header (the latter being the correct one) caused a dependency loop and ultimately dbus.socket to be dropped. So this is about the priority number and nothing else? If so, then I am happy to take a patch that drops taking the chkconfig priority number into account entirely, while leaving the rest of chkconfig parsing in there, unconditionally. That should fix the immediate bug you are encountering, right? I have commited such a change now. Can you verify if this improves things for you? I think the priority information is irrelevant in this particular issue. It's the discrepancy regarding runlevel information. So I doubt your patch makes a difference, but I'll double check. I am tempted to also drop the runlevel parsing from the LSB and chkconfig headers. After all they are mostly irrelevant since what is linked in /etc/rc?.d/ is what matters, and not the stuff in the init script themselves. Let me now if this would make things work then for you. If so, I'll drop this too then. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
