[gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Systemd is diametrically opposed to the FreeBSD, customization, extreme configurability, and top-notch developer community aspects of that. Systemd upstream developers have made it abundantly clear they are not interested in working with Gentoo developers to see to the needs of source-based distros. They stand for vertical integration instead of customization and configurability. And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. Then, it will require people working on it. People who know the details of various systems and who are willing to spend their time on it. And there wouldn't be much of people really willing to work on it. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 00:14:36 +0800 Ben de Groot yng...@gentoo.org wrote: Systemd is diametrically opposed to the FreeBSD, customization, extreme configurability, and top-notch developer community aspects of that. Systemd upstream developers have made it abundantly clear they are not interested in working with Gentoo developers to see to the needs of source-based distros. They stand for vertical integration instead of customization and configurability. And you misunderstood: it is systemd that is aggressively opposed to Gentoo. But apparently that doesn't bother some of our developers and Gentoo is becoming more and more welcoming to it. By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. Then, it will require people working on it. People who know the details of various systems and who are willing to spend their time on it. And there wouldn't be much of people really willing to work on it. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? I agree it would be pretty hard to carve out a niche for this. Personally I would see more in runit. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. Rich
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. Rich +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. Robert.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 9:37 AM, Michał Górny wrote: By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Unit files had been considered when I started exploring the idea, sadly Joost shown me their limitation wouldn't make people life exactly happy. Although some of the ideas (esp. wrt targets) are near to crazy and awfully hard to understand, that's what we have and trying to do something else is eventually going to make people's lives harder. Making better mousetraps usually works fine: as long you have generators that are good enough to get something working nobody would complain. We should *really* work on supporting the unit files within OpenRC (aside to init.d files). That's a way to at least: a) reuse the work that has been done upstream already (when it was done), b) have common service names and startup behavior in all relevant distros (which is really beneficial to the users). Can be done notwithstanding the rest. Considering the design of OpenRC itself, it wouldn't be *that hard*. It is sort of simple. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. A compiler is an option as well, as said unit - runscript should map fine. On the completely different topic, I agree that systemd design is far from the best and the way it's maintained is just bad. I was interested in the past in creating an improved alternative using compatible file format and libraries, while choosing a better design, improving portability and keeping stuff less integrated. But the fact is -- I doubt it will make sense, much like the eudev project. And it will take much more work, and give much less appreciation. Having stand alone component would probably win you many friends and if the whole thing could work on something non-linux-latest-with-latest-glibc you'd have one less technical concern. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. You make clean blueprints, get enough people agreeing with them and implement simple workalike for what you care about. For example logind seems to be the current fad. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. systemd haters, as you name them, could be split in few groups: - those that consider systemd a bad idea because it is a single item with many parts that would break horribly, if your idea is to make it less tightly coupled and with less parts many would consider helping. - those that consider systemd a bad idea because of the force feeding theme started with udev incorporation and continued with logind and such, again if you are creating alternatives the people would help gladly. - those that consider key part of systemd just wrong the limitation in the unit format or path activation as panacea, in that case you have to make clear the scope of your project, you might win few or lose some. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. Make it bsd and they would consider helping. It is possible that systemd upstream will steal a few patches or ideas from it. Yet they will never apply any of the really important changes, so the project will have to be maintained indefinitely. The only hope for it would be to win over systemd users which I doubt will happen. Or just make something useful, winning or losing is for the people using it. If it works and works fine people will use it. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? Probably would be better sit down, figure out exactly what you want and see who has interest: E.g. Init-project - portable - must work on non-linux and non-glibc more or less decently - modular- loose coupling of functionality - robust - the core functionality must not crash or remain inconsistent because of libdbus or such often occurring problems unrelated to - compatible - should grok at least a good subset of systemd unit files. On a side note I
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 1) we waste disk space. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. 3) if user modifies systemd unit, init.d script is out-of-sync. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, May 26, 2013 at 6:31 AM, Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. 3) if user modifies systemd unit, init.d script is out-of-sync. To clarify, I was agreeing with the use of a wrapper script - likely symlinked. It would not be compiled/generated at install time, beyond creating the symlink and maybe a conf.d file that pointed to the unit. The eclass would just streamline the installation. As you point out that keeps the configs always in-sync. It also means that if the wrapper script is upgraded to add new features all packages benefit, without needing a re-install. Rich
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On Sun, 26 May 2013 12:23:51 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 9:37 AM, Michał Górny wrote: By the way, we should really keep the separation between systemd itself and the unit files. I agree that systemd is not the best thing we could have. But the unit file format is, er, good enough -- and has the advantage of eventually taking a lot of work from our shoulders. Unit files had been considered when I started exploring the idea, sadly Joost shown me their limitation wouldn't make people life exactly happy. There are always people who are unhappy with anything you'd change. Sometimes it's just about changing the way you see things. I can't tell more without knowing the details though. First of all, working on it will require a lot of work. Seeing how large systemd become and how rapidly it is developing, establishing a good alternative (even dropping such useless parts as the Journal) will take at least twice that work. You make clean blueprints, get enough people agreeing with them and implement simple workalike for what you care about. For example logind seems to be the current fad. You're probably right here. But I would have to have the time to work on it, and as you probably noticed I'm engaged in too many projects right now. The systemd haters will refuse the project because of its resemblance to systemd. The systemd lovers will refuse it because of its resemblance to systemd. And the OpenRC lovers will want to design it to resemble OpenRC which is just pointless. Then the few remaining people will find systemd 'good enough'. systemd haters, as you name them, could be split in few groups: - those that consider systemd a bad idea because it is a single item with many parts that would break horribly, if your idea is to make it less tightly coupled and with less parts many would consider helping. - those that consider systemd a bad idea because of the force feeding theme started with udev incorporation and continued with logind and such, again if you are creating alternatives the people would help gladly. - those that consider key part of systemd just wrong the limitation in the unit format or path activation as panacea, in that case you have to make clear the scope of your project, you might win few or lose some. You are right again. The outcome would be probably a very modular project which some parts will be used more frequently and others infrequently. But the fact is -- that as far as I see it -- we should be working on replacing all of systemd components. Mixing tightly-coupled parts of systemd with external replacements seems wrong. And even if there are a few people who will want to work on it, and design a 'good systemd', they wouldn't get much appreciation. Fedora definitely won't care for it. It would have to be really definitely awesome for most Linux distros to even notice it. And I doubt *BSD people would be interested in something external. Make it bsd and they would consider helping. I'm not really sure about this. For some of the components probably yes. But the general init replacement / unit runner is not something I'd expect much help with. So there's a lot of work, no fame or money in it, and most likely more work being the only future. Anyone volunteering? Probably would be better sit down, figure out exactly what you want and see who has interest: E.g. Init-project - portable - must work on non-linux and non-glibc more or less decently - modular- loose coupling of functionality - robust - the core functionality must not crash or remain inconsistent because of libdbus or such often occurring problems unrelated to - compatible - should grok at least a good subset of systemd unit files. Quite a good summary, I'd say. On a side note I really want to know in detail why you loathe openrc with this strength but we can discuss on irc. I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. I have my limits, and I'd really prefer doing something useful rather than setting up random things straight, fighting developers and making sure everything keeps working in a semi-sane way. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd (was: Going against co-maintainer's wishes (ref. bug 412697))
On Sun, 26 May 2013 12:31:25 +0200 Michał Górny mgo...@gentoo.org wrote: On Sun, 26 May 2013 12:12:49 +0200 Robert David robert.david.pub...@gmail.com wrote: On Sun, 26 May 2013 05:49:48 -0400 Rich Freeman ri...@gentoo.org wrote: On Sun, May 26, 2013 at 4:32 AM, Ben de Groot yng...@gentoo.org wrote: On 26 May 2013 15:37, Michał Górny mgo...@gentoo.org wrote: Considering the design of OpenRC itself, it wouldn't be *that hard*. Actually, a method similar to one used in oldnet would simply work. That is, symlinking init.d files to a common 'systemd-wrapper' executable which would parse the unit files. I think this idea actually makes sense. Re-using upstream work seems a logical idea, and could ease maintenance. Of course the issue is whether the OpenRC devs see any benefit in this. Init.d scripts are just shell scripts. All somebody needs to do is write a shell script that parses a unit file and does what it says, and exports an openrc-oriented init.d environment. That can be packaged separately, or whatever, and maybe an eclass could make it easy to install (point it at the upstream/filesdir unit and tell it what to call the init.d script, and you get the appropriate symlink/script). The OpenRC devs don't have to endorse anything - sure it would make sense to bundle it, but it could just as easily be pulled in as a dep or used manually by a user. The script could ignore any unit features that aren't implemented. You can ignore settings like auto-restart/inetd and just use the settings that get the daemon started. +1 I would rather add shell script to parse unit and generate appropriate init script while building than have initscript wrapper that will call and parse on execution. As you said, some eclass. This effectively duplicates data for no real benefit. 1) we waste disk space. Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. 2) if user modifies init.d script, systemd unit is out-of-sync. And the init.d is rewritten (potentially with CONFIG_PROTECT) on next upgrade. If someone update iniscript, must be prepared to be outofsync with package version. Thus CONFIG_PROTECT. 3) if user modifies systemd unit, init.d script is out-of-sync. Why someone will modify systemd unit when will be using init.d scripts. And for those few people doing this, the same script as portage use for converting can be used. Robert.
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 1:31 PM, Robert David wrote: Come on, it is 2013, wasting few inodes. I did not got these problems in the old good times with my 386 with 4mb ram and few MB hdd. Those with embedded system will mask many other files, not only systemd units (so they save one inode more with my approach, when need no initscript-wrapper). Users of regular server/desktops/laptops, 10-20 inodes more? They would rather won't use Gentoo with its portage tree or do not compile kernel sources, etc. The fact we are already the worst offenders won't make thinking about impacting a little less not that important. System with the problem keep portage in a separate fs. lu
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 1:15 PM, Michał Górny wrote: I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. Here we have a problem, the people that need more flexibility to actually get work done will see that the inflexibility of the unit format will bite them and bite them hard. A simple example is something fairly easy for a runscript and quite annoying for an unit, multiple instances. for openrc you can just symlink using a proper pattern and have the initscript figure the right configuration and which user/chroot use to drop the daemon. for systemd you have to copy and edit since most fields are immutable (some are with special rules). This is something you tend to use a lot for certain kind of services and is made really easy and uniform in openrc while lsb and freebsd tend to have per-script rules. I have my limits, and I'd really prefer doing something useful rather than setting up random things straight, fighting developers and making sure everything keeps working in a semi-sane way. Your dedication is commendable, I do appreciate your help in Gentoo a lot even if we can disagree on some decisions. I know that discussing systemd can get quite annoying since it can easily drift from technical (e.g. my concern regarding dbus) political (systemd as Trojan horse for something else and other strategical concerns), or personal (some people consider Lennart a dangerous/poisonous person) and gets quite easy to mix things up and end up discounting technical concerns by telling that you said this or that just because you hate Lennart. lu
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On Sun, 26 May 2013 13:59:34 +0200 Luca Barbato lu_z...@gentoo.org wrote: On 5/26/13 1:15 PM, Michał Górny wrote: I'd suspect this is mostly with the growing irritation of systemd haters who spawn endless threads about how they hate anything with 'systemd' name in it. Plus the people who try hard to port the mistakes of OpenRC init scripts to systemd services files. Here we have a problem, the people that need more flexibility to actually get work done will see that the inflexibility of the unit format will bite them and bite them hard. A simple example is something fairly easy for a runscript and quite annoying for an unit, multiple instances. for openrc you can just symlink using a proper pattern and have the initscript figure the right configuration and which user/chroot use to drop the daemon. You need to name a unit with @ suffix, like openvpn@.service: $ cat /etc/systemd/system/openvpn@.service [Service] Type=simple ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf feel free to sprinkle %i (and others) for templating. and symlink it as you like. openvpn@foo.service (or openvpn@foo) will be direct analogue to openvpn.foo. (+ foo.service.d with the same(?) override semantics) for systemd you have to copy and edit since most fields are immutable (some are with special rules). .include /path/to/unit OverrideedField = OverridedValue will not help here, right? -- Sergei signature.asc Description: PGP signature
Re: [gentoo-dev] Reusing systemd unit file format / forking systemd
On 5/26/13 3:35 PM, Sergei Trofimovich wrote: On Sun, 26 May 2013 13:59:34 +0200 Luca Barbato lu_z...@gentoo.org wrote: You need to name a unit with @ suffix, like openvpn@.service: $ cat /etc/systemd/system/openvpn@.service [Service] Type=simple ExecStart=/usr/sbin/openvpn --user openvpn --group openvpn --cd /etc/openvpn --chroot /var/run/openvpn --config %I.conf feel free to sprinkle %i (and others) for templating. Feel free to check which fields accept %expansions and which do not, last time I heard some fields do not. If it had been fixed I'm glad. lu
