On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
> > There are still a lot of unit files missing; we should create a todo
> > list. It would also be helpful to write down a simple wiki page with
> > some guidelines here.
>
> Did I miss something or did you miss the Jan's todo list[1]?
>
> > E.g. I am not sure if we should read those
> > /etc/conf.d/$damon files from the unit files as well or drop these as
> > the user should override unit files in /etc.
>
> Indeed, I was wondering if we should adapt our packages to the layout used by
> the upstream systemd services files. E.g. the upstream proftpd service sources
> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.

So there is no standard for this, and the general recommendation is that
if you disagree with the default command line args the service in /lib
provides, you should simply override the service in /etc. If anything,
I'd vote that /etc/conf.d (or whatever other name you give it) should
slowly shrink/disappear over time.

d

On Tuesday 14 August 2012 12:57:37 Dave Reisner wrote:
> So there is no standard for this, and the general recommendation is that
> if you disagree with the default command line args the service in /lib
> provides, you should simply override the service in /etc. If anything,
> I'd vote that /etc/conf.d (or whatever other name you give it) should
> slowly shrink/disappear over time.

Ok, so since there's no standard I'm fine with Pierre's idea to write the
default parameters in the service files and drop the conf.d*whatever files.

--
Andrea

On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner <d@falconindy.com> wrote:
> On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
>> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
>> > There are still a lot of unit files missing; we should create a todo
>> > list. It would also be helpful to write down a simple wiki page with
>> > some guidelines here.
>>
>> Did I miss something or did you miss the Jan's todo list[1]?
>>
>> > E.g. I am not sure if we should read those
>> > /etc/conf.d/$damon files from the unit files as well or drop these as
>> > the user should override unit files in /etc.
>>
>> Indeed, I was wondering if we should adapt our packages to the layout used by
>> the upstream systemd services files. E.g. the upstream proftpd service sources
>> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
>
> So there is no standard for this, and the general recommendation is that
> if you disagree with the default command line args the service in /lib
> provides, you should simply override the service in /etc. If anything,
> I'd vote that /etc/conf.d (or whatever other name you give it) should
> slowly shrink/disappear over time.

What does the non-standard think about distro-provided updates to the
units? Seems like with overriding the whole thing rather than small
pieces in a separate config file, it isn't obvious to the user when
they need to merge updates to the unit files.

-Dan

On Tue, Aug 14, 2012 at 6:57 PM, Dave Reisner <d@falconindy.com> wrote:
> On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
>> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
>> > There are still a lot of unit files missing; we should create a todo
>> > list. It would also be helpful to write down a simple wiki page with
>> > some guidelines here.
>>
>> Did I miss something or did you miss the Jan's todo list[1]?
>>
>> > E.g. I am not sure if we should read those
>> > /etc/conf.d/$damon files from the unit files as well or drop these as
>> > the user should override unit files in /etc.
>>
>> Indeed, I was wondering if we should adapt our packages to the layout used by
>> the upstream systemd services files. E.g. the upstream proftpd service sources
>> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
>
> So there is no standard for this, and the general recommendation is that
> if you disagree with the default command line args the service in /lib
> provides, you should simply override the service in /etc. If anything,
> I'd vote that /etc/conf.d (or whatever other name you give it) should
> slowly shrink/disappear over time.
>
> d
>

This approach would also necessitate educating our users about running
systemd-delta after upgrades. Users might end up having overridden
units that got updated, and as a result, break.

On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote:
> On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner <d@falconindy.com> wrote:
> > On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
> >> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
> >> > There are still a lot of unit files missing; we should create a todo
> >> > list. It would also be helpful to write down a simple wiki page with
> >> > some guidelines here.
> >>
> >> Did I miss something or did you miss the Jan's todo list[1]?
> >>
> >> > E.g. I am not sure if we should read those
> >> > /etc/conf.d/$damon files from the unit files as well or drop these as
> >> > the user should override unit files in /etc.
> >>
> >> Indeed, I was wondering if we should adapt our packages to the layout used by
> >> the upstream systemd services files. E.g. the upstream proftpd service sources
> >> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
> >
> > So there is no standard for this, and the general recommendation is that
> > if you disagree with the default command line args the service in /lib
> > provides, you should simply override the service in /etc. If anything,
> > I'd vote that /etc/conf.d (or whatever other name you give it) should
> > slowly shrink/disappear over time.
>
> What does the non-standard think about distro-provided updates to the
> units? Seems like with overriding the whole thing rather than small
> pieces in a separate config file, it isn't obvious to the user when
> they need to merge updates to the unit files.
>
> -Dan

It's possible to include unit files (.include /lib/systemd/....), though
in practice, I haven't seen how well this works.

On Aug 14, 2012 7:17 PM, "Dave Reisner" <d@falconindy.com> wrote:
>
> On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote:
> > On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner <d@falconindy.com> wrote:
> > > On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:
> > >> On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:
> > >> > There are still a lot of unit files missing; we should create a
todo
> > >> > list. It would also be helpful to write down a simple wiki page
with
> > >> > some guidelines here.
> > >>
> > >> Did I miss something or did you miss the Jan's todo list[1]?
> > >>
> > >> > E.g. I am not sure if we should read those
> > >> > /etc/conf.d/$damon files from the unit files as well or drop these
as
> > >> > the user should override unit files in /etc.
> > >>
> > >> Indeed, I was wondering if we should adapt our packages to the
layout used by
> > >> the upstream systemd services files. E.g. the upstream proftpd
service sources
> > >> /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.
> > >
> > > So there is no standard for this, and the general recommendation is
that
> > > if you disagree with the default command line args the service in /lib
> > > provides, you should simply override the service in /etc. If anything,
> > > I'd vote that /etc/conf.d (or whatever other name you give it) should
> > > slowly shrink/disappear over time.
> >
> > What does the non-standard think about distro-provided updates to the
> > units? Seems like with overriding the whole thing rather than small
> > pieces in a separate config file, it isn't obvious to the user when
> > they need to merge updates to the unit files.
> >
> > -Dan
>
> It's possible to include unit files (.include /lib/systemd/....), though
> in practice, I haven't seen how well this works.

There its also systemd-delta, which makes this much easier to deal with.

Tom

Am 14.08.2012 16:57, schrieb Stéphane Gaudreault:
> Systemd has a overall better design than SysV, lots of useful
> administrative features and provide quicker boot up. Considering that
> it has been around in our repositories for some time and that it could
> be considered stable enough for production use, I would suggest to
> replace iniscript by systemd once the 'Missing systemd units' is over.
> Thus we will avoid duplicating our efforts on two init systems.
>
> Any objections to start the migration process ?
>
> Cheers,
>
> Stéphane
>
>
+1 I use systemd on all my machines.

greetings
tpowa

--
Tobias Powalowski
Archlinux Developer & Package Maintainer (tpowa)
http://www.archlinux.org
tpowa@archlinux.org

On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault
<stephane@archlinux.org> wrote:
> Systemd has a overall better design than SysV, lots of useful administrative
> features and provide quicker boot up. Considering that it has been around in
> our repositories for some time and that it could be considered stable enough
> for production use, I would suggest to replace iniscript by systemd once the
> 'Missing systemd units' is over. Thus we will avoid duplicating our efforts
> on two init systems.
>
> Any objections to start the migration process ?
>
> Cheers,
>
> Stéphane
>
>

+1

Ronald

On Tue, Aug 14, 2012 at 10:57 AM, Stéphane Gaudreault
<stephane@archlinux.org> wrote:
> Systemd has a overall better design than SysV, lots of useful administrative
> features and provide quicker boot up. Considering that it has been around in
> our repositories for some time and that it could be considered stable enough
> for production use, I would suggest to replace iniscript by systemd once the
> 'Missing systemd units' is over. Thus we will avoid duplicating our efforts
> on two init systems.
>
> Any objections to start the migration process ?
>
> Cheers,
>
> Stéphane
>
>

+1.

I don't use systemd or know how it works or compare to initscripts but
I am aware that we'll need to switch to it eventually as more and more
projects will depends on it. So the sooner the better.

Eric

On 15 August 2012 07:32, Eric Bélanger <snowmaniscool@gmail.com> wrote:
> On Tue, Aug 14, 2012 at 10:57 AM, Stéphane Gaudreault
> <stephane@archlinux.org> wrote:
>> Systemd has a overall better design than SysV, lots of useful administrative
>> features and provide quicker boot up. Considering that it has been around in
>> our repositories for some time and that it could be considered stable enough
>> for production use, I would suggest to replace iniscript by systemd once the
>> 'Missing systemd units' is over. Thus we will avoid duplicating our efforts
>> on two init systems.
>>
>> Any objections to start the migration process ?
>>
>> Cheers,
>>
>> Stéphane
>>
>>
>
> +1.
>
> I don't use systemd or know how it works or compare to initscripts but
> I am aware that we'll need to switch to it eventually as more and more
> projects will depends on it. So the sooner the better.
>
> Eric

Exactly the same position, +1.


--
GPG/PGP ID: C0711BF1