F15 Feature - convert as many service init files as possible to the native SystemD services

[Michał Piotrowski]

Hi,

I would like to help with scripts conversion. IMO the conversion
action should be coordinated.

Comments, thoughts?

Kind regards,
Michal

[Ville Skyttä]

On Sunday 21 November 2010, Michał Piotrowski wrote:
>  Hi,
>  
>  I would like to help with scripts conversion. IMO the conversion
>  action should be coordinated.
>  
>  Comments, thoughts? 
Sure.  But just in case by coordination you happen imply that a small team of 
volunteers would be doing the grunt work, I think it's useful if instead of 
that as many maintainers as possible are involved with doing it hands on so 
more people get familiar with it.

[Michał Piotrowski]

2010/11/21 Ville Skyttä <ville.skytta(a)iki.fi&gt;:
>  On Sunday 21 November 2010, Michał Piotrowski wrote:
> > Hi,
> >
> > I would like to help with scripts conversion. IMO the conversion
> > action should be coordinated.
> >
> > Comments, thoughts?
>
>  Sure.  But just in case by coordination you happen imply that a small team of
>  volunteers would be doing the grunt work, 
Basically yes.

>  I think it's useful if instead of
>  that as many maintainers as possible are involved with doing it hands on so
>  more people get familiar with it. 
No problem. We can create a list of all scripts in wiki and
maintainers of individual packages would indicate that they want to
convert scripts themselves.

Without coordination we would not known how many scripts are already
converted and how many need rewrite.

Best regards,
Michal

[Michał Piotrowski]

W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
<mkkp4x4(a)gmail.com&gt; napisał:
>  We can create a list of all scripts in wiki and
>  maintainers of individual packages would indicate that they want to
>  convert scripts themselves. 
How can I get information about all packages that provides init scripts?

When I do
rpm -qf /etc/init.d/*
I get only information about already installed packages. Any magic
switch to get informations about all packages from rpm database?

Best regards,
Michal

[Bruno Wolff III]

On Tue, Nov 23, 2010 at 17:18:44 +0100,
  Michał Piotrowski <mkkp4x4(a)gmail.com&gt; wrote:
>  W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
>  <mkkp4x4(a)gmail.com&gt; napisał:
>  > We can create a list of all scripts in wiki and
>  > maintainers of individual packages would indicate that they want to
>  > convert scripts themselves.
>  
>  How can I get information about all packages that provides init scripts?
>  
>  When I do
>  rpm -qf /etc/init.d/*
>  I get only information about already installed packages. Any magic
>  switch to get informations about all packages from rpm database? 
I believe rpm only knows about packages available locally. You either need
to have the packages installed or a local mirror. (You can use urls to
refer to remote packages with rpm, but that isn't likely to be workable.)
If you have a local mirror you can use the p option and name the rpms.

Otherwise yum is probably a better choice for this, since it can use meta
data to get information. One of the yum utilities may be better than yum
itself, but I am not sure offhand.

[James Antill]

On Tue, 2010-11-23 at 10:19 -0600, Bruno Wolff III wrote:
>  On Tue, Nov 23, 2010 at 17:18:44 +0100,
>    Michał Piotrowski <mkkp4x4(a)gmail.com&gt; wrote:
>  > W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
>  > <mkkp4x4(a)gmail.com&gt; napisał:
>  > > We can create a list of all scripts in wiki and
>  > > maintainers of individual packages would indicate that they want to
>  > > convert scripts themselves.
>  > 
>  > How can I get information about all packages that provides init scripts?
>  > 
>  > When I do
>  > rpm -qf /etc/init.d/*
>  > I get only information about already installed packages. Any magic
>  > switch to get informations about all packages from rpm database?
>  
>  I believe rpm only knows about packages available locally. You either need
>  to have the packages installed or a local mirror. (You can use urls to
>  refer to remote packages with rpm, but that isn't likely to be workable.)
>  If you have a local mirror you can use the p option and name the rpms.
>  
>  Otherwise yum is probably a better choice for this, since it can use meta
>  data to get information. One of the yum utilities may be better than yum
>  itself, but I am not sure offhand. 
 You can use:

repoquery -qf '/etc/init.d/*' '/etc/rc.d/init.d/*'

...note that unlike "rpm -qf" you need both of the above paths.

[Jason L Tibbitts III]

> >>>> "MP" == Michał Piotrowski
> <mkkp4x4(a)gmail.com&gt; writes: 
MP> How can I get information about all packages that provides init
MP> scripts?

repoquery --whatprovides '/etc/init.d/*'

 - J<

[Michał Piotrowski]

2010/11/23 Jason L Tibbitts III <tibbs(a)math.uh.edu&gt;:
> >>>>> "MP" == Michał Piotrowski
> <mkkp4x4(a)gmail.com&gt; writes:
>
>  MP> How can I get information about all packages that provides init
>  MP> scripts?
>
>  repoquery --whatprovides '/etc/init.d/*' 
It seems to me that too little packages was returned

>   - J<
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Bill Nottingham]

Michał Piotrowski (mkkp4x4(a)gmail.com) said: 
>  > MP> How can I get information about all packages that
> provides init
>  > MP> scripts?
>  >
>  > repoquery --whatprovides '/etc/init.d/*'
>  
>  It seems to me that too little packages was returned 
Add '/etc/rc.d/init.d/*' too; while they both resolve to the same place,
the filelist might have it in either.

Bill

[Rudolf Kastl]

2010/11/23 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
>  <mkkp4x4(a)gmail.com&gt; napisał:
> > We can create a list of all scripts in wiki and
> > maintainers of individual packages would indicate that they want to
> > convert scripts themselves.
>
>  How can I get information about all packages that provides init scripts?
>
>  When I do
>  rpm -qf /etc/init.d/*
>  I get only information about already installed packages. Any magic
>  switch to get informations about all packages from rpm database? 
no because only installed packages are part of the rpmdb. you could do
yum install '/etc/init.d/*' then you have all the material to convert
;)

kind regards,
Rudolf Kastl

>  Best regards,
>  Michal
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Michal Schmidt]

On Tue, 23 Nov 2010 17:18:44 +0100 Michał Piotrowski wrote:
>  How can I get information about all packages that provides init
>  scripts?
>  
>  When I do
>  rpm -qf /etc/init.d/*
>  I get only information about already installed packages. Any magic
>  switch to get informations about all packages from rpm database? 
repoquery -f /etc{,/rc.d}/init.d/\*

[Philippe Makowski]

2010/11/23 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
>  <mkkp4x4(a)gmail.com&gt; napisał:
> > We can create a list of all scripts in wiki and
> > maintainers of individual packages would indicate that they want to
> > convert scripts themselves. 
I'll try to do it for Firebird package
can you give me some hints and place I have to read before ?

[Michał Piotrowski]

W dniu 23 listopada 2010 18:35 użytkownik philippe makowski
<makowski.fedora(a)gmail.com&gt; napisał:
>  2010/11/23 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
> > W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
> > <mkkp4x4(a)gmail.com&gt; napisał:
> >> We can create a list of all scripts in wiki and
> >> maintainers of individual packages would indicate that they want to
> >> convert scripts themselves.
>  I'll try to do it for Firebird package
>  can you give me some hints and place I have to read before ? 
This is a good start point
http://0pointer.de/blog/projects/systemd-for-admins-3.html

About services, sockets, targets etc
http://0pointer.de/public/systemd-man/

You may want to read all systemd related things from
http://0pointer.de/blog/
(if you don't know how it works, you should start from begining)

Best regards,
Michal

[Lennart Poettering]

On Tue, 23.11.10 18:44, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  
>  W dniu 23 listopada 2010 18:35 użytkownik philippe makowski
>  <makowski.fedora(a)gmail.com&gt; napisał:
>  > 2010/11/23 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  >> W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
>  >> <mkkp4x4(a)gmail.com&gt; napisał:
>  >>> We can create a list of all scripts in wiki and
>  >>> maintainers of individual packages would indicate that they want to
>  >>> convert scripts themselves.
>  > I'll try to do it for Firebird package
>  > can you give me some hints and place I have to read before ?
>  
>  This is a good start point
>  http://0pointer.de/blog/projects/systemd-for-admins-3.html
>  
>  About services, sockets, targets etc
>  http://0pointer.de/public/systemd-man/
>  
>  You may want to read all systemd related things from
>  http://0pointer.de/blog/
>  (if you don't know how it works, you should start from begining) 
Most important is actually the draft of the packaging guide for systemd:

http://fedoraproject.org/wiki/Systemd_Packaging_Draft

(see the lower part of it, ignore the top)

Also, of particular interest is
http://0pointer.de/public/systemd-man/daemon.html.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Jóhann B. Guðmundsson]

On 11/20/2010 11:46 PM, Michał Piotrowski wrote:
>  Hi,
>
>  I would like to help with scripts conversion. IMO the conversion
>  action should be coordinated.
>
>  Comments, thoughts?
>
>  Kind regards,
>  Michal 
I created this a while back so just take your pick from there fill it 
with a link to the new file when you are done and the corresponding bz 
report or package build

https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

Thank you.

JBG

[Michał Piotrowski]

2010/11/23 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com&gt;:
>  On 11/20/2010 11:46 PM, Michał Piotrowski wrote:
> > Hi,
> >
> > I would like to help with scripts conversion. IMO the conversion
> > action should be coordinated.
> >
> > Comments, thoughts?
> >
> > Kind regards,
> > Michal
>
>  I created this a while back so just take your pick from there fill it
>  with a link to the new file when you are done and the corresponding bz
>  report or package build 
This is exactly what I wanted :)

>  https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability
>
>  Thank you.
>
>  JBG
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Best regards,
Michal

[Lennart Poettering]

On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  Hi,
>  
>  I would like to help with scripts conversion. IMO the conversion
>  action should be coordinated.
>  
>  Comments, thoughts? 
I would certainly welcome any work in this direction!

I think it would make sense to use Johann's page in the wiki as the
central place to keep track of this:

https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability

In another mail on this thread there was already a list of documentation
posted. If you need real-life examples how this should look like, then
consider having a look on a packge such as bluez (keep however in mind
that this package predates the packaging daft, so if in doubt the draft
is right and the package is wrong... ;-)).

Also note that ideally services that currently are exclusively bus
activated gain native systemd files as well, so that they for the first
time can be controlled, supervised and introspected like any other
service on the system.

This adds the following packages to the list of packages to convert:

abrt accountsservice ailurus avahi blueman bluez ConsoleKit
cups-pk-helper dconf fprintd GConf2 gnome-applets gnome-lirc-properties
gnome-settings-daemon gnome-system-monitor gypsy hal kdebase-runtime
kdebase-workspace ModemManager NetworkManager PackageKit polkit rtkit
sectool setroubleshoot system-config-firewall system-config-kdump
system-config-samba system-config-services systemd udisks upower
wpa_supplicant.

(A number of these are already converted actually)

If you have any questions regarding writing service files, refer to the
linked documentation, especially the packaging draft:

https://fedoraproject.org/wiki/Systemd_Packaging_Draft#Scriptlets

(Note that this is still a draft, and not official, so take it with a
pinch of salt!)

Also, have a look into the already converted service files in
/lib/systemd/system/*. Note however that service files for stuff
involved in early boot and late shutdown are not suitable as an example,
since they are very different than the service files of normal services,
since early boot/late shutdown services have manually configured
dependencies. You can easily recognize them by the
DefaultDependencies=no setting. Don't be confused by those, just ignore
them!

Of course, the helpful folks on #systemd on freenode will be happy to
answer any questions you might have, and especially I myself will be
(mezcalero). However, for the next weeks I'll be backpacking through
India and not be particularly responsive.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Michał Piotrowski]

2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
>  On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>
> > Hi,
> >
> > I would like to help with scripts conversion. IMO the conversion
> > action should be coordinated.
> >
> > Comments, thoughts?
>
>  I would certainly welcome any work in this direction! 
Could you look at the
crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
and
atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
and see if I did not do any fundamental error?

Seems to me that these are simple enough at the beginning :)

For both I used Type=forking - it works fine, but it seems to me that
Type=simple might be a better choice.

Best regards,
Michal

[Tomasz Torcz]

On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
>  2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
>  > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>  >
>  >> Hi,
>  >>
>  >> I would like to help with scripts conversion. IMO the conversion
>  >> action should be coordinated.
>  >>
>  >> Comments, thoughts?
>  >
>  > I would certainly welcome any work in this direction!
>  
>  Could you look at the
>  crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
>  and
>  atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
>  and see if I did not do any fundamental error?
>  
>  Seems to me that these are simple enough at the beginning :)
>  
>  For both I used Type=forking - it works fine, but it seems to me that
>  Type=simple might be a better choice. 
  For type=simple you would like “-n” switch in crond invocation.
I suggest trimming Description, it is printed during bootup and should be short. 

-- 
Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg(a)chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton
(LKML)

[Michał Piotrowski]

2010/11/24 Tomasz Torcz <tomek(a)pipebreaker.pl&gt;:
>  On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
> > 2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
> > > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
> > >
> > >> Hi,
> > >>
> > >> I would like to help with scripts conversion. IMO the conversion
> > >> action should be coordinated.
> > >>
> > >> Comments, thoughts?
> > >
> > > I would certainly welcome any work in this direction!
> >
> > Could you look at the
> > crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
> > and
> > atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
> > and see if I did not do any fundamental error?
> >
> > Seems to me that these are simple enough at the beginning :)
> >
> > For both I used Type=forking - it works fine, but it seems to me that
> > Type=simple might be a better choice.
>
>   For type=simple you would like "-n" switch in crond invocation. 
Ah, ok, I'll keep forking.

>  I suggest trimming Description, it is printed during bootup and
> should be short. 
I didn't noticed it - I guess "quiet" kernel param is also interpreted
by SystemD.

>  --
>  Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
>  xmpp: zdzichubg(a)chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton
> (LKML)
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Kind regards,
Michal

[Lennart Poettering]

On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  
>  2010/11/24 Tomasz Torcz <tomek(a)pipebreaker.pl&gt;:
>  > On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
>  >> 2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
>  >> > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>  >> >
>  >> >> Hi,
>  >> >>
>  >> >> I would like to help with scripts conversion. IMO the conversion
>  >> >> action should be coordinated.
>  >> >>
>  >> >> Comments, thoughts?
>  >> >
>  >> > I would certainly welcome any work in this direction!
>  >>
>  >> Could you look at the
>  >> crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
>  >> and
>  >> atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
>  >> and see if I did not do any fundamental error?
>  >>
>  >> Seems to me that these are simple enough at the beginning :)
>  >>
>  >> For both I used Type=forking - it works fine, but it seems to me that
>  >> Type=simple might be a better choice.
>  >
>  >  For type=simple you would like "-n" switch in crond invocation.
>  
>  Ah, ok, I'll keep forking. 
It's generally nicer to use "simple" wherever possible, unless you have
a really good reason to assume that your service might be needed to be
up by something else, and that something else might want synchronize to
it. Since at/cron don't really offer any live protocols to other
processes I think Type=simple is a good idea here.

BTW, regarding at and cron: what I was thinking of but never check
ehwther it is feasible is to make cron/at autostart a soon as some job
is scheduled. I.e. use .path trigger to check whether /etc/crontab and
user jobs exist, and start cron only then. Similarly for at. That way we
could support cron and at just fine, and wouldn't even have to run it by
default. I haven't looked into this in detail however, to see if the
file triggers systemd offers in .path units are already sufficient to
make this work.

(And /etc/cron.daily and stuff would then be managed by systemd
natively, in a .timer unit)

>  > I suggest trimming Description, it is printed during bootup and
> should be short.
>  
>  I didn't noticed it - I guess "quiet" kernel param is also interpreted
>  by SystemD. 
Yes, systemd honours "quiet":

Btw, it's written "systemd", not "SystemD". I even added a section
about
the spelling now to the systemd homepage ;-)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Paul Wouters]

On Wed, 24 Nov 2010, Lennart Poettering wrote:

>  BTW, regarding at and cron: what I was thinking of but never check
>  ehwther it is feasible is to make cron/at autostart a soon as some job
>  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  user jobs exist, and start cron only then. Similarly for at. That way we
>  could support cron and at just fine, and wouldn't even have to run it by
>  default. I haven't looked into this in detail however, to see if the
>  file triggers systemd offers in .path units are already sufficient to
>  make this work. 
What if no jobs are there and a non-root user adds a crontab later on? Who
will start cron (as root) ?

>  Btw, it's written "systemd", not "SystemD". I
> even added a section about
>  the spelling now to the systemd homepage ;-) 
At Openswan, we never wrote OpenSWAN and we're still telling people every week
to not use that. It's a lost battle :P

Paul

[Michał Piotrowski]

2010/11/24 Paul Wouters <paul(a)xelerance.com&gt;:
>  On Wed, 24 Nov 2010, Lennart Poettering wrote:
>
> > BTW, regarding at and cron: what I was thinking of but never check
> > ehwther it is feasible is to make cron/at autostart a soon as some job
> > is scheduled. I.e. use .path trigger to check whether /etc/crontab and
> > user jobs exist, and start cron only then. Similarly for at. That way we
> > could support cron and at just fine, and wouldn't even have to run it by
> > default. I haven't looked into this in detail however, to see if the
> > file triggers systemd offers in .path units are already sufficient to
> > make this work.
>
>  What if no jobs are there and a non-root user adds a crontab later on? Who
>  will start cron (as root) ? 
I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
how systemd interprets wildcards and multiple ListenStream)

> > Btw, it's written "systemd", not "SystemD". I even added a
> section about
> > the spelling now to the systemd homepage ;-)
>
>  At Openswan, we never wrote OpenSWAN and we're still telling people every week
>  to not use that. It's a lost battle :P
>
>  Paul
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
Kind regards,
Michal

[Tomasz Torcz]

On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote:
>  2010/11/24 Paul Wouters <paul(a)xelerance.com&gt;:
>  > On Wed, 24 Nov 2010, Lennart Poettering wrote:
>  >
>  >> BTW, regarding at and cron: what I was thinking of but never check
>  >> ehwther it is feasible is to make cron/at autostart a soon as some job
>  >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  >> user jobs exist, and start cron only then. Similarly for at. That way we
>  >> could support cron and at just fine, and wouldn't even have to run it by
>  >> default. I haven't looked into this in detail however, to see if the
>  >> file triggers systemd offers in .path units are already sufficient to
>  >> make this work.
>  >
>  > What if no jobs are there and a non-root user adds a crontab later on? Who
>  > will start cron (as root) ?
>  
>  I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
>  how systemd interprets wildcards and multiple ListenStream) 
 
  Uhm, you meant path type unit, described in systemd.path surely. Listen* 
directives are for sockets.


>  >
>  >> Btw, it's written "systemd", not "SystemD". I even added
> a section about
>  >> the spelling now to the systemd homepage ;-)
>  >
>  > At Openswan, we never wrote OpenSWAN and we're still telling people every week
>  > to not use that. It's a lost battle :P 
  And Paul surely meant OpenS/WAN ;)

-- 
Tomasz Torcz                 "God, root, what's the difference?"
xmpp: zdzichubg(a)chrome.pl         "God is more forgiving."

[Michał Piotrowski]

W dniu 24 listopada 2010 21:34 użytkownik Tomasz Torcz
<tomek(a)pipebreaker.pl&gt; napisał:
>  On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski wrote:
> > 2010/11/24 Paul Wouters <paul(a)xelerance.com&gt;:
> > > On Wed, 24 Nov 2010, Lennart Poettering wrote:
> > >
> > >> BTW, regarding at and cron: what I was thinking of but never check
> > >> ehwther it is feasible is to make cron/at autostart a soon as some job
> > >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and
> > >> user jobs exist, and start cron only then. Similarly for at. That way we
> > >> could support cron and at just fine, and wouldn't even have to run it
> by
> > >> default. I haven't looked into this in detail however, to see if the
> > >> file triggers systemd offers in .path units are already sufficient to
> > >> make this work.
> > >
> > > What if no jobs are there and a non-root user adds a crontab later on? Who
> > > will start cron (as root) ?
> >
> > I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
> > how systemd interprets wildcards and multiple ListenStream)
>
>   Uhm, you meant path type unit, described in systemd.path surely. Listen*
>  directives are for sockets. 
Probably yes :)

> > >
> > >> Btw, it's written "systemd", not "SystemD". I even
> added a section about
> > >> the spelling now to the systemd homepage ;-)
> > >
> > > At Openswan, we never wrote OpenSWAN and we're still telling people every
> week
> > > to not use that. It's a lost battle :P
>
>   And Paul surely meant OpenS/WAN ;)
>
>  --
>  Tomasz Torcz                 "God, root, what's the difference?"
>  xmpp: zdzichubg(a)chrome.pl         "God is more forgiving."
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Lennart Poettering]

On Wed, 24.11.10 21:30, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  
>  2010/11/24 Paul Wouters <paul(a)xelerance.com&gt;:
>  > On Wed, 24 Nov 2010, Lennart Poettering wrote:
>  >
>  >> BTW, regarding at and cron: what I was thinking of but never check
>  >> ehwther it is feasible is to make cron/at autostart a soon as some job
>  >> is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  >> user jobs exist, and start cron only then. Similarly for at. That way we
>  >> could support cron and at just fine, and wouldn't even have to run it by
>  >> default. I haven't looked into this in detail however, to see if the
>  >> file triggers systemd offers in .path units are already sufficient to
>  >> make this work.
>  >
>  > What if no jobs are there and a non-root user adds a crontab later on? Who
>  > will start cron (as root) ?
>  
>  I guess ListenStream=/var/spool/cron/* (if it will work - I'm not sure
>  how systemd interprets wildcards and multiple ListenStream) 
Almost. This is a .path unit, the syntax is:

DirectoryNotEmpty=/var/spool/cron

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Michał Piotrowski]

Someone uses cherokee web server? Please check this service
https://bugzilla.redhat.com/show_bug.cgi?id=657085

Kind regards,
Michal

[Lennart Poettering]

On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  
>  Someone uses cherokee web server? Please check this service
>  https://bugzilla.redhat.com/show_bug.cgi?id=657085 
Looks good (haven't tested it though, and don't really know
cherokee). In this case however, I think it would actually make sense to
use Type=forking and pass "-d". Why? Because another service might want
to access cherokee over HTTP or so and if you don't use Type=forking
then that other service is using After=cherokee.service it might access
it before the server is actually up.

BTW, is the -C /etc/cherokee/cherokee.conf really necessary?
Independently of systemd i Actually believe we should simplify the
command lines as much as possible, and if /etc/cherokee/cherokee.conf is
the default config file anyway I think it would be nice to drop that
argument.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Michał Piotrowski]

2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
>  On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>
> >
> > Someone uses cherokee web server? Please check this service
> > https://bugzilla.redhat.com/show_bug.cgi?id=657085
>
>  Looks good (haven't tested it though, and don't really know
>  cherokee). In this case however, I think it would actually make sense to
>  use Type=forking and pass "-d". Why? Because another service might want
>  to access cherokee over HTTP or so and if you don't use Type=forking
>  then that other service is using After=cherokee.service it might access
>  it before the server is actually up. 
Ok, I changed it to forking (I tried it before and it didn't worked
after reboot - I think that the httpd.socket had something to do with
that)

>  BTW, is the -C /etc/cherokee/cherokee.conf really necessary?
>  Independently of systemd i Actually believe we should simplify the
>  command lines as much as possible, and if /etc/cherokee/cherokee.conf is
>  the default config file anyway I think it would be nice to drop that
>  argument. 
Ok, agree.

I created second version without "-C /path/to/config" - let maintainer
choose the right version in his opinion.

>  Lennart
>
>  --
>  Lennart Poettering - Red Hat, Inc.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Kind regards,
Michal

[Michał Piotrowski]

I wanted to convert httpd, and I saw that it's already converted and
it uses socket

httpd.socket
ListenStream=80

What if administrator want to change port to other? Let's say, that
I've got configured three servers:
80 - cherokee
81 - apache
82 - nginx

In this enviroment httpd.socket should trigger cherokee not apache.
Parameter to ListenStream should be taken from server config somehow.
Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf |
cut -d " " -f 2 in ListenStream?

Best regards,
Michal

[Lennart Poettering]

On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  I wanted to convert httpd, and I saw that it's already converted
> and
>  it uses socket
>  
>  httpd.socket
>  ListenStream=80 
Where do I find this? Its not in the pkg git tree nor in bugzilla?

>  What if administrator want to change port to other? Let's say,
> that
>  I've got configured three servers:
>  80 - cherokee
>  81 - apache
>  82 - nginx 
The recommended way to modify the default configuration is to copy
/lib/systemd/system/httpd.socket to /etc/systemd/system/httpd.socket and
then edit it there. That way you can easily drop back to the default
setup by deleting this file again. Files in /etc/systemd/system take
precedence over those equally named in /lib/systemd/system.

>  In this enviroment httpd.socket should trigger cherokee not apache.
>  Parameter to ListenStream should be taken from server config somehow.
>  Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf |
>  cut -d " " -f 2 in ListenStream? 
No, we don't support that really. And I am not convinced we should.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Michał Piotrowski]

2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
>  On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>
> > I wanted to convert httpd, and I saw that it's already converted and
> > it uses socket
> >
> > httpd.socket
> > ListenStream=80
>
>  Where do I find this? Its not in the pkg git tree nor in bugzilla? 
O LOL.... sorry for the noise :)
I created it six days ego :)

> > What if administrator want to change port to other? Let's say, that
> > I've got configured three servers:
> > 80 - cherokee
> > 81 - apache
> > 82 - nginx
>
>  The recommended way to modify the default configuration is to copy
>  /lib/systemd/system/httpd.socket to /etc/systemd/system/httpd.socket and
>  then edit it there. That way you can easily drop back to the default
>  setup by deleting this file again. Files in /etc/systemd/system take
>  precedence over those equally named in /lib/systemd/system. 
Ok

> > In this enviroment httpd.socket should trigger cherokee not apache.
> > Parameter to ListenStream should be taken from server config somehow.
> > Is it possible tu run magic grep ^Listen /etc/httpd/conf/httpd.conf |
> > cut -d " " -f 2 in ListenStream?
>
>  No, we don't support that really. And I am not convinced we should.
>
>  Lennart
>
>  --
>  Lennart Poettering - Red Hat, Inc.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Best regards,
Michal

[Lennart Poettering]

On Wed, 24.11.10 15:22, Paul Wouters (paul(a)xelerance.com) wrote:

>  
>  On Wed, 24 Nov 2010, Lennart Poettering wrote:
>  
>  > BTW, regarding at and cron: what I was thinking of but never check
>  > ehwther it is feasible is to make cron/at autostart a soon as some job
>  > is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  > user jobs exist, and start cron only then. Similarly for at. That way we
>  > could support cron and at just fine, and wouldn't even have to run it by
>  > default. I haven't looked into this in detail however, to see if the
>  > file triggers systemd offers in .path units are already sufficient to
>  > make this work.
>  
>  What if no jobs are there and a non-root user adds a crontab later on? Who
>  will start cron (as root) ? 
That's the point of the .path unit. i.e. you can list dirs to watch. If
a user then drop a file into one of those dirs cron gets automatically
started.

Basically, in your .path unit you'd write something like this:

[Path]
PathExists=/etc/crontab
DirectoryNotEmpty=/etc/cron.d
DirectoryNotEmpty=/var/spool/cron

And the moment where /etc/crontab starts to exist, or somebody drops a
file into /etc/cron.d or /var/spool/cron crond would be automatically
started.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Tomas Mraz]

On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote: 
>  On Wed, 24.11.10 15:22, Paul Wouters (paul(a)xelerance.com) wrote:
>  
>  > 
>  > On Wed, 24 Nov 2010, Lennart Poettering wrote:
>  > 
>  > > BTW, regarding at and cron: what I was thinking of but never check
>  > > ehwther it is feasible is to make cron/at autostart a soon as some job
>  > > is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  > > user jobs exist, and start cron only then. Similarly for at. That way we
>  > > could support cron and at just fine, and wouldn't even have to run it by
>  > > default. I haven't looked into this in detail however, to see if the
>  > > file triggers systemd offers in .path units are already sufficient to
>  > > make this work.
>  > 
>  > What if no jobs are there and a non-root user adds a crontab later on? Who
>  > will start cron (as root) ?
>  
>  That's the point of the .path unit. i.e. you can list dirs to watch. If
>  a user then drop a file into one of those dirs cron gets automatically
>  started.
>  
>  Basically, in your .path unit you'd write something like this:
>  
>  [Path]
>  PathExists=/etc/crontab
>  DirectoryNotEmpty=/etc/cron.d
>  DirectoryNotEmpty=/var/spool/cron
>  
>  And the moment where /etc/crontab starts to exist, or somebody drops a
>  file into /etc/cron.d or /var/spool/cron crond would be automatically
>  started. 
But what is the point of this? The /etc/crontab always exists and there
always are some files in /etc/cron.d.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Michał Piotrowski]

2010/11/25 Tomas Mraz <tmraz(a)redhat.com&gt;:
>  On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
> > That's the point of the .path unit. i.e. you can list dirs to watch. If
> > a user then drop a file into one of those dirs cron gets automatically
> > started.
> >
> > Basically, in your .path unit you'd write something like this:
> >
> > [Path]
> > PathExists=/etc/crontab
> > DirectoryNotEmpty=/etc/cron.d
> > DirectoryNotEmpty=/var/spool/cron
> >
> > And the moment where /etc/crontab starts to exist, or somebody drops a
> > file into /etc/cron.d or /var/spool/cron crond would be automatically
> > started.
>
>  But what is the point of this? The /etc/crontab always exists and there
>  always are some files in /etc/cron.d. 
Actually it's true, but in the near future all standard cron jobs
might be runned by systemd

http://0pointer.de/public/systemd-man/systemd.timer.html

It's not 100 % cron replacement now, but who knows what the future holds :)

Kind regards,
Michal

[Tomas Mraz]

On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: 
>  2010/11/25 Tomas Mraz <tmraz(a)redhat.com&gt;:
>  > On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
>  >> That's the point of the .path unit. i.e. you can list dirs to watch. If
>  >> a user then drop a file into one of those dirs cron gets automatically
>  >> started.
>  >>
>  >> Basically, in your .path unit you'd write something like this:
>  >>
>  >> [Path]
>  >> PathExists=/etc/crontab
>  >> DirectoryNotEmpty=/etc/cron.d
>  >> DirectoryNotEmpty=/var/spool/cron
>  >>
>  >> And the moment where /etc/crontab starts to exist, or somebody drops a
>  >> file into /etc/cron.d or /var/spool/cron crond would be automatically
>  >> started.
>  >
>  > But what is the point of this? The /etc/crontab always exists and there
>  > always are some files in /etc/cron.d.
>  
>  Actually it's true, but in the near future all standard cron jobs
>  might be runned by systemd
>  
>  http://0pointer.de/public/systemd-man/systemd.timer.html
>  
>  It's not 100 % cron replacement now, but who knows what the future holds :) 
I suppose the future holds systemd replacing the whole operating system.
Resistance is futile. You will be assimilated. :)
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Tomas Mraz]

On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote: 
>  2010/11/25 Tomas Mraz <tmraz(a)redhat.com&gt;:
>  > On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
>  >> That's the point of the .path unit. i.e. you can list dirs to watch. If
>  >> a user then drop a file into one of those dirs cron gets automatically
>  >> started.
>  >>
>  >> Basically, in your .path unit you'd write something like this:
>  >>
>  >> [Path]
>  >> PathExists=/etc/crontab
>  >> DirectoryNotEmpty=/etc/cron.d
>  >> DirectoryNotEmpty=/var/spool/cron
>  >>
>  >> And the moment where /etc/crontab starts to exist, or somebody drops a
>  >> file into /etc/cron.d or /var/spool/cron crond would be automatically
>  >> started.
>  >
>  > But what is the point of this? The /etc/crontab always exists and there
>  > always are some files in /etc/cron.d.
>  
>  Actually it's true, but in the near future all standard cron jobs
>  might be runned by systemd
>  
>  http://0pointer.de/public/systemd-man/systemd.timer.html
>  
>  It's not 100 % cron replacement now, but who knows what the future holds :) 
To add some argument to my previous sarcasm. I do not think that it
makes any sense to replicate cron functionality in systemd. Either you
replicate half of it and then you still need to run crond for the rest
or you replicate it completely. But in that case what is the saving over
the separate daemon? I'm sorry but I do not think that crond is anything
that "optimized out" by inclusion can improve performance of Linux
desktop/server/whatever. I do not say that cronie code cannot be
improved - it definitely can - but it does not make any sense to
reimplement it from scratch.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Michał Piotrowski]

W dniu 25 listopada 2010 17:33 użytkownik Tomas Mraz <tmraz(a)redhat.com&gt; napisał:
>  On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote:
> > Actually it's true, but in the near future all standard cron jobs
> > might be runned by systemd
> >
> > http://0pointer.de/public/systemd-man/systemd.timer.html
> >
> > It's not 100 % cron replacement now, but who knows what the future holds :)
>
>  To add some argument to my previous sarcasm. I do not think that it
>  makes any sense to replicate cron functionality in systemd. 
I do not know if it ever replace crond (I don't know Lennarts goals
here), but having actual systemd.timer functionality in system daemon
is IMHO very useful thing.

>  Either you
>  replicate half of it and then you still need to run crond for the rest
>  or you replicate it completely. But in that case what is the saving over
>  the separate daemon? I'm sorry but I do not think that crond is anything
>  that "optimized out" by inclusion can improve performance of Linux
>  desktop/server/whatever. I do not say that cronie code cannot be
>  improved - it definitely can - but it does not make any sense to
>  reimplement it from scratch.
>  --
>  Tomas Mraz
>  No matter how far down the wrong road you've gone, turn back.
>                                               Turkish proverb
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
Best regards,
Michal

[Lennart Poettering]

On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:

>  > Actually it's true, but in the near future all standard cron
> jobs
>  > might be runned by systemd
>  > 
>  > http://0pointer.de/public/systemd-man/systemd.timer.html
>  > 
>  > It's not 100 % cron replacement now, but who knows what the future holds :)
>  
>  To add some argument to my previous sarcasm. I do not think that it
>  makes any sense to replicate cron functionality in systemd. Either you
>  replicate half of it and then you still need to run crond for the rest
>  or you replicate it completely. But in that case what is the saving over
>  the separate daemon? I'm sorry but I do not think that crond is anything
>  that "optimized out" by inclusion can improve performance of Linux
>  desktop/server/whatever. I do not say that cronie code cannot be
>  improved - it definitely can - but it does not make any sense to
>  reimplement it from scratch. 
crond is not particularly complex. And providing similar functionality
in systemd is relatively easy as the more complicated stuff cron does is
actually spawning the processes, and systemd is vastly more powerful
with that. i.e. you can set IO/CPU schedulers, get sane logging, get all
the cgroups niftyness, you can pull in extra deps, yadda yadda.

Also, what's particularly interesting is that you can combine various
triggers if you do this in systemd: i.e. have one timer-based trigger,
and one inotify trigger (i.e. .path unit), and they start the same job,
and you don't end up with duplicates and need locking. 

And also, cron does a couple of really nasty things. For example it
wakes up in regular intervals to check if a job is ready to run. It does
so to deal with wallclock time changes/suspends. In systemd we are
working on a different way to solve this, so that we can actually sleep
as long as possible, and don't have to wake up in regular
intervals. Also, this means we can have much more accurate time
specifications, and we don't have to pay a price for it, due to
this. This different design will even allow us to do amazing stuff that
hasn't existed so far, for example, mark cron jobs so that they wake up
the machine from suspend, and similar.

To summarize this: the current logic of cron is not pretty. And it
duplicates process spawning and babysitting which already exists in way
too many daemons, and is actually the more interesting code. systemd
unifies all that code, and the end result will be simpler, more powerful
and less code, since we reuse what already exists anyway. The only thing
we basically add to systemd is a parser for calendar events, and
everything else already exists.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
>  And also, cron does a couple of really nasty things. For example it
>  wakes up in regular intervals to check if a job is ready to run. It does
>  so to deal with wallclock time changes/suspends. In systemd we are
>  working on a different way to solve this, so that we can actually sleep
>  as long as possible, and don't have to wake up in regular
>  intervals. Also, this means we can have much more accurate time
>  specifications, and we don't have to pay a price for it, due to
>  this. This different design will even allow us to do amazing stuff that
>  hasn't existed so far, for example, mark cron jobs so that they wake up
>  the machine from suspend, and similar.
>  
>  To summarize this: the current logic of cron is not pretty. And it
>  duplicates process spawning and babysitting which already exists in way
>  too many daemons, and is actually the more interesting code. systemd
>  unifies all that code, and the end result will be simpler, more powerful
>  and less code, since we reuse what already exists anyway. The only thing
>  we basically add to systemd is a parser for calendar events, and
>  everything else already exists.
>  
>  Lennart
>  
>  -- 
>  Lennart Poettering - Red Hat, Inc.

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
>  On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:
>  And also, cron does a couple of really nasty things. For example it
>  wakes up in regular intervals to check if a job is ready to run. It does
>  so to deal with wallclock time changes/suspends. In systemd we are
>  working on a different way to solve this, so that we can actually sleep
>  as long as possible, and don't have to wake up in regular
>  intervals. 
Great.  You can fix cron then, this does not mean it is necessary to
integrate the two.

>  To summarize this: the current logic of cron is not pretty. And it
>  duplicates process spawning and babysitting which already exists in way
>  too many daemons, 
I think you'll find the execution of processes is a
comparatively small
part of cron.  And anyway, "process spawning and babysitting" will
_always_ exist in many different daemons, unless you want to run the
whole system within a single systemd process.  It would be much much
better for the ecosystem to extract these parts of systemd into a
library (perhaps standalone, perhaps interacting with the system-wide
systemd runtime) that can be used in any other process that needs to run
a task in a separately tracked "daemon group".
    Mirek

[Lennart Poettering]

On Fri, 26.11.10 02:07, Miloslav Trmač (mitr(a)volny.cz) wrote:

>  Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
>  > On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:
>  > And also, cron does a couple of really nasty things. For example it
>  > wakes up in regular intervals to check if a job is ready to run. It does
>  > so to deal with wallclock time changes/suspends. In systemd we are
>  > working on a different way to solve this, so that we can actually sleep
>  > as long as possible, and don't have to wake up in regular
>  > intervals.
>  Great.  You can fix cron then, this does not mean it is necessary to
>  integrate the two. 
Well, I actually believe we should design an OS here, not just a set of
independent tools. And that means I think closer integration is good and
only has benefits.

>  > To summarize this: the current logic of cron is not pretty. And
> it
>  > duplicates process spawning and babysitting which already exists in way
>  > too many daemons,
>  I think you'll find the execution of processes is a comparatively small
>  part of cron.   
Well, and that's why it is also very limited.

>  And anyway, "process spawning and babysitting" will
>  _always_ exist in many different daemons, unless you want to run the
>  whole system within a single systemd process.   
Sure, no doubt about that. But unifying this for system stuff is a good
thing, not a bad thing.

>  It would be much much better for the ecosystem to extract these
> parts
>  of systemd into a library (perhaps standalone, perhaps interacting
>  with the system-wide systemd runtime) that can be used in any other
>  process that needs to run a task in a separately tracked "daemon
>  group".  Mirek 
Well, I don't think that that technically makes any sense. Sorry.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Miloslav Trmač]

Lennart Poettering píše v Pá 26. 11. 2010 v 03:05 +0100:
>  On Fri, 26.11.10 02:07, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  > Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
>  > > On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:
>  > > And also, cron does a couple of really nasty things. For example it
>  > > wakes up in regular intervals to check if a job is ready to run. It does
>  > > so to deal with wallclock time changes/suspends. In systemd we are
>  > > working on a different way to solve this, so that we can actually sleep
>  > > as long as possible, and don't have to wake up in regular
>  > > intervals.
>  > Great.  You can fix cron then, this does not mean it is necessary to
>  > integrate the two.
>  
>  Well, I actually believe we should design an OS here, not just a set of
>  independent tools. And that means I think closer integration is good and
>  only has benefits. 
At the very least, closer integration makes troubleshooting
significantly more difficult.  Each point where separate tools interact
is a point where it is possible, and in UNIX often easy, to insert
debugging instrumentation.

If the system integrates everything into one process, the only remaining
troubleshooting mechanisms are integrated logging (which is by
definition unsatisfactory - if a problem was foreseen enough to be
logged, it was probably also foreseen enough to be avoided), debugger
(useless for non-programmers, useless for non-expert programmers that
need to fix things in a hurry, practically useless with -O2) and
systemtap (only a little better than a debugger, and not available for
most programs).

"Design an OS" means that the system _design_ should fit well together,
nothing more.

>  > It would be much much better for the ecosystem to extract these
> parts
>  > of systemd into a library (perhaps standalone, perhaps interacting
>  > with the system-wide systemd runtime) that can be used in any other
>  > process that needs to run a task in a separately tracked "daemon
>  > group".  Mirek
>  
>  Well, I don't think that that technically makes any sense. Sorry. 
Care to
elaborate?  Look at sshd: it needs to start per-user sessions
from a single daemon.  Wouldn't it make sense to track these as cgroups
recognized by systemd?  Crond is _exactly_ the same thing.  Any other
remote access protocol (POSIX batch facilities, func, X server accepting
remote clients, and anything else that isn't currently a part of the
system and thus can't be rewritten as part of systemd) would benefit
from this facility.

AFAICS it would be clearly useful to be able to delegate the control of
"daemon group" creation to other processes.  Why doesn't it make sense?
	Mirek

[Frank Ch. Eigler]

Miloslav =?UTF-8?Q?Trma=C4=8D?= <mitr(a)volny.cz&gt; writes:

>  [...]  If the system integrates everything into one process, the
>  only remaining troubleshooting mechanisms are integrated logging
>  [...], debugger [...]  and systemtap (only a little better than a
>  debugger, and not available for most programs). 
To clarify, systemtap is "available for most programs" on fedora, to
the extent that most C or C++ programs can be probed with systemtap,
including those without <sys/sdt.h> compiled-in stuff.  For example:

   probe process("a.out").function("foobar") { log($$parms$$) }
   probe process("a.out").statement("*@file.c:100-200") {
log($$vars$$) }

There is also some support for interpreters like java and python too.

- FChE

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  Well, I actually believe we should design an OS here, not just a set
> of
>  independent tools. And that means I think closer integration is good and
>  only has benefits. 
But this is a Unix-like OS, where each tool does one (or few) things and
does them well.  systemd is not the OS, it is just one tool.  Please
don't try to subsume the entire OS into systemd.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Genes MailLists]

On 11/25/2010 11:01 PM, Chris Adams wrote:
>  Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt;
> said:
> > Well, I actually believe we should design an OS here, not just a set of
> > independent tools. And that means I think closer integration is good and
> > only has benefits.
>  
>  But this is a Unix-like OS, where each tool does one (or few) things and
>  does them well.  systemd is not the OS, it is just one tool.  Please
>  don't try to subsume the entire OS into systemd.
>   
 Lets get systemd working well and as close to dammit as bug free please
.. before we start having it take over other parts of the OS ...

[Tomas Mraz]

On Thu, 2010-11-25 at 23:11 -0500, Genes MailLists wrote: 
>  On 11/25/2010 11:01 PM, Chris Adams wrote:
>  > Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  >> Well, I actually believe we should design an OS here, not just a set of
>  >> independent tools. And that means I think closer integration is good and
>  >> only has benefits.
>  > 
>  > But this is a Unix-like OS, where each tool does one (or few) things and
>  > does them well.  systemd is not the OS, it is just one tool.  Please
>  > don't try to subsume the entire OS into systemd.
>  > 
>  
>   Lets get systemd working well and as close to dammit as bug free please
>  .. before we start having it take over other parts of the OS ... 
+99

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Michał Piotrowski]

Hi,

How to start things that really are not demons?

Amtu seemed to be a simple service to convert

[Unit]
Description=Abstract Machine Tests
After=syslog.target

[Service]
EnvironmentFile=/etc/sysconfig/amtu
ExecStart=/usr/sbin/amtu $EXTRAOPTIONS

[Install]
WantedBy=multi-user.target

sudo systemctl start amtu.service
sudo systemctl status amtu.service
amtu.service - Abstract Machine Tests
	  Loaded: loaded (/lib/systemd/system/amtu.service)
	  Active: active (running) since Fri, 26 Nov 2010 18:13:47 +0100; 1s ago
	Main PID: 2092 (amtu)
	  CGroup: name=systemd:/system/amtu.service
		  └ 2092 /usr/sbin/amtu
sudo systemctl status amtu.service
amtu.service - Abstract Machine Tests
	  Loaded: loaded (/lib/systemd/system/amtu.service)
	  Active: failed since Fri, 26 Nov 2010 18:13:50 +0100; 632ms ago
	Main PID: 2092 (code=exited, status=255)
	  CGroup: name=systemd:/system/amtu.service

It's because it's not really a daemon.
sudo /usr/sbin/amtu
Executing Memory Test...
Memory Test SUCCESS!
Executing Memory Separation Test...
Memory Separation Test SUCCESS!
Executing Network I/O Tests...
Failed to get list of network interfaces to test.
Executing I/O Controller - Disk Test...
I/O Controller - Disk Test SUCCESS!
Executing Supervisor Mode Instructions Test...
Privileged Instruction Test SUCCESS!

This service runs for a few seconds and exit.

How to start it properly?

Best regards,
Michal

[Tomasz Torcz]

On Fri, Nov 26, 2010 at 03:42:33PM +0100, Michał Piotrowski wrote:
>  Hi,
>  
>  How to start things that really are not demons?
>  
>  Amtu seemed to be a simple service to convert
>  
>  [Unit]
>  Description=Abstract Machine Tests
>  After=syslog.target
>  
>  [Service]
>  EnvironmentFile=/etc/sysconfig/amtu
>  ExecStart=/usr/sbin/amtu $EXTRAOPTIONS
>  
>  [Install]
>  WantedBy=multi-user.target
>  
>  This service runs for a few seconds and exit.
>  How to start it properly? 
  Type=oneshot  (decribed in man systemd.service). Also, RemainAfterExit=
property could be useful.
  But is this really a “service“?  What's the role of AMTU?

-- 
Tomasz Torcz       ,,(...) today's high-end is tomorrow's embedded
processor.''
xmpp: zdzichubg(a)chrome.pl                      -- Mitchell Blank on LKML

[Michał Piotrowski]

2010/11/26 Tomasz Torcz <tomek(a)pipebreaker.pl&gt;:
>  On Fri, Nov 26, 2010 at 03:42:33PM +0100, Michał Piotrowski wrote:
> > Hi,
> >
> > How to start things that really are not demons?
> >
> > Amtu seemed to be a simple service to convert
> >
> > [Unit]
> > Description=Abstract Machine Tests
> > After=syslog.target
> >
> > [Service]
> > EnvironmentFile=/etc/sysconfig/amtu
> > ExecStart=/usr/sbin/amtu $EXTRAOPTIONS
> >
> > [Install]
> > WantedBy=multi-user.target
> >
> > This service runs for a few seconds and exit.
> > How to start it properly?
>
>   Type=oneshot  (decribed in man systemd.service). 
I tried it
amtu.service - Abstract Machine Tests
	  Loaded: loaded (/lib/systemd/system/amtu.service)
	  Active: failed since Fri, 26 Nov 2010 19:12:48 +0100; 11s ago
	 Process: 2557 (/usr/sbin/amtu $EXTRAOPTIONS, code=exited, status=255)
	  CGroup: name=systemd:/system/amtu.service

>  Also, RemainAfterExit=
>  property could be useful. 
also tried
RemainAfterExit=yes
amtu.service - Abstract Machine Tests
	  Loaded: loaded (/lib/systemd/system/amtu.service)
	  Active: failed since Fri, 26 Nov 2010 19:14:35 +0100; 2s ago
	 Process: 2602 (/usr/sbin/amtu $EXTRAOPTIONS, code=exited, status=255)
	  CGroup: name=systemd:/system/amtu.service


>   But is this really a "service"? 
It has init script

>   What's the role of AMTU? 
# description:  This service runs the abstract machine tests to check the \
#               underlying security assumptions. It can be configured to
#               halt the machine in the event of failure. The program does
#               not stay resident, but rather runs once.

Frankly, it's this first time I met with this :)

Best regards,
Michal

>  --
>  Tomasz Torcz       ,,(...) today's high-end is tomorrow's embedded
> processor.''
>  xmpp: zdzichubg(a)chrome.pl                      -- Mitchell Blank on LKML
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel

[Lennart Poettering]

On Fri, 26.11.10 16:18, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

Sorry for not responding earlier to this, I have been travelling the
last few weeks with little access to the internet.
>  
>  I tried it
>  amtu.service - Abstract Machine Tests
>  	  Loaded: loaded (/lib/systemd/system/amtu.service)
>  	  Active: failed since Fri, 26 Nov 2010 19:12:48 +0100; 11s ago
>  	 Process: 2557 (/usr/sbin/amtu $EXTRAOPTIONS, code=exited, status=255)
>  	  CGroup: name=systemd:/system/amtu.service 
Your process simply exists with status=255, systemd records that and
give that it is != 0 it will make the service enter "failed" state. 

Previously the exit code of init scripts did not matter much in
sysvinit, and was usually eaten up. However, in systemd we actually
record if things failed to start up and present them to the user/admin
in "systemctl status". This is actually a great advantage of systemd,
even if it sounds trivial enough. It should be a useful tool for admins
to track down services that don't work and why they don't work.

In your specific case it's probably a good idea trying to track down
what exit code 255 means, and maybe look for a message in syslog
explaining what went wrong in the service.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Tomas Mraz]

On Fri, 2010-11-26 at 03:05 +0100, Lennart Poettering wrote: 
>  On Fri, 26.11.10 02:07, Miloslav Trmač (mitr(a)volny.cz) wrote:
>  
>  > Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
>  > > On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:
>  > > And also, cron does a couple of really nasty things. For example it
>  > > wakes up in regular intervals to check if a job is ready to run. It does
>  > > so to deal with wallclock time changes/suspends. In systemd we are
>  > > working on a different way to solve this, so that we can actually sleep
>  > > as long as possible, and don't have to wake up in regular
>  > > intervals.
>  > Great.  You can fix cron then, this does not mean it is necessary to
>  > integrate the two.
>  
>  Well, I actually believe we should design an OS here, not just a set of
>  independent tools. And that means I think closer integration is good and
>  only has benefits. 
I agree you are trying to design a completely new OS here. I am not so
sure this OS will be better than any other fully integrated monolithic
OS. I originally did not want to write this, but it seems you are really
determined to break some of the basic and proven to be effective Unix
design philosophy rules to make the system from simple parts with
clearly defined interfaces and functionality.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Tomas Mraz]

On Fri, 2010-11-26 at 02:07 +0100, Miloslav Trmač wrote: 
>  Lennart Poettering píše v Pá 26. 11. 2010 v 01:27 +0100:
>  > On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:
>  > And also, cron does a couple of really nasty things. For example it
>  > wakes up in regular intervals to check if a job is ready to run. It does
>  > so to deal with wallclock time changes/suspends. In systemd we are
>  > working on a different way to solve this, so that we can actually sleep
>  > as long as possible, and don't have to wake up in regular
>  > intervals.
>  Great.  You can fix cron then, this does not mean it is necessary to
>  integrate the two.
>  
>  > To summarize this: the current logic of cron is not pretty. And it
>  > duplicates process spawning and babysitting which already exists in way
>  > too many daemons,
>  I think you'll find the execution of processes is a comparatively small
>  part of cron.  And anyway, "process spawning and babysitting" will
>  _always_ exist in many different daemons, unless you want to run the
>  whole system within a single systemd process.  It would be much much
>  better for the ecosystem to extract these parts of systemd into a
>  library (perhaps standalone, perhaps interacting with the system-wide
>  systemd runtime) that can be used in any other process that needs to run
>  a task in a separately tracked "daemon group". 
+1

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb

[Marcela Mašláňová]

On 11/26/2010 01:27 AM, Lennart Poettering wrote:
>  On Thu, 25.11.10 17:33, Tomas Mraz (tmraz(a)redhat.com) wrote:
>
> >> Actually it's true, but in the near future all standard cron jobs
> >> might be runned by systemd
> >>
> >> http://0pointer.de/public/systemd-man/systemd.timer.html
> >>
> >> It's not 100 % cron replacement now, but who knows what the future holds :)
> > To add some argument to my previous sarcasm. I do not think that it
> > makes any sense to replicate cron functionality in systemd. Either you
> > replicate half of it and then you still need to run crond for the rest
> > or you replicate it completely. But in that case what is the saving over
> > the separate daemon? I'm sorry but I do not think that crond is anything
> > that "optimized out" by inclusion can improve performance of Linux
> > desktop/server/whatever. I do not say that cronie code cannot be
> > improved - it definitely can - but it does not make any sense to
> > reimplement it from scratch.
>  crond is not particularly complex. And providing similar functionality
>  in systemd is relatively easy as the more complicated stuff cron does is
>  actually spawning the processes, and systemd is vastly more powerful
>  with that. i.e. you can set IO/CPU schedulers, get sane logging, get all
>  the cgroups niftyness, you can pull in extra deps, yadda yadda.
>
>  Also, what's particularly interesting is that you can combine various
>  triggers if you do this in systemd: i.e. have one timer-based trigger,
>  and one inotify trigger (i.e. .path unit), and they start the same job,
>  and you don't end up with duplicates and need locking. 
>
>  And also, cron does a couple of really nasty things. For example it
>  wakes up in regular intervals to check if a job is ready to run. It does
>  so to deal with wallclock time changes/suspends. In systemd we are
>  working on a different way to solve this, so that we can actually sleep
>  as long as possible, and don't have to wake up in regular
>  intervals. Also, this means we can have much more accurate time
>  specifications, and we don't have to pay a price for it, due to
>  this. This different design will even allow us to do amazing stuff that
>  hasn't existed so far, for example, mark cron jobs so that they wake up
>  the machine from suspend, and similar.
>  
Cronie is using inotify, so it doesn't wake every minute as it used to.

I'm just curious, how many programmes would stay in Fedora after
you finish systemd ;-) </sarcasm>.

Marcela

-- 
Marcela Mašláňová
BaseOS team Brno

[Adam Williamson]

On Fri, 2010-11-26 at 07:42 +0100, Marcela Mašláňová wrote:

>  I'm just curious, how many programmes would stay in Fedora after
>  you finish systemd ;-) </sarcasm>. 
and do we run systemd in emacs, or emacs from systemd?!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Lennart Poettering]

On Thu, 25.11.10 08:39, Tomas Mraz (tmraz(a)redhat.com) wrote:

>  > That's the point of the .path unit. i.e. you can list dirs
> to watch. If
>  > a user then drop a file into one of those dirs cron gets automatically
>  > started.
>  > 
>  > Basically, in your .path unit you'd write something like this:
>  > 
>  > [Path]
>  > PathExists=/etc/crontab
>  > DirectoryNotEmpty=/etc/cron.d
>  > DirectoryNotEmpty=/var/spool/cron
>  > 
>  > And the moment where /etc/crontab starts to exist, or somebody drops a
>  > file into /etc/cron.d or /var/spool/cron crond would be automatically
>  > started.
>  
>  But what is the point of this? The /etc/crontab always exists and there
>  always are some files in /etc/cron.d. 
The only contents of /etc/crontab and /etc/cron.d is the lines to handle
/etc/cron.daily and friends. As mentioned we can easily run those as
normal timer-triggerd units inside of systemd itself (and get all the
features it offers you for free, nice introspection, logging, IO/CPU
scheduling hooks, yadda yadda). So, if you remove that /etc/crontab is
empty and hence could be removed. And /etc/cron.d is empty too. And
there you go, we can support cron jobs just fine, but won't even start
it on most machines, but the user won't se the difference in the
behaviour.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Andrew Clayton]

On Fri, 26 Nov 2010 01:15:04 +0100, Lennart Poettering wrote:

>  The only contents of /etc/crontab and /etc/cron.d is the lines to
>  handle /etc/cron.daily and friends. As mentioned we can easily run 
On RHEL/CentOS (and it's likely only a matter of time before systemd
fillers through to them) various programs install jobs into /etc/cron.d
a quick look on one machine shows; mailman and sysstat related jobs as
well as some others...

>  those as normal timer-triggerd units inside of systemd itself (and
>  get all the features it offers you for free, nice introspection,
>  logging, IO/CPU scheduling hooks, yadda yadda). So, if you remove
>  that /etc/crontab is empty and hence could be removed.
>  And /etc/cron.d is empty too. And there you go, we can support cron 
Although I can't be the only one who puts various cron jobs
under /etc/cron.d that get run at various times.

Andrew

[Lennart Poettering]

On Fri, 26.11.10 00:46, Andrew Clayton (andrew(a)digital-domain.net) wrote:

>  
>  On Fri, 26 Nov 2010 01:15:04 +0100, Lennart Poettering wrote:
>  
>  > The only contents of /etc/crontab and /etc/cron.d is the lines to
>  > handle /etc/cron.daily and friends. As mentioned we can easily run
>  
>  On RHEL/CentOS (and it's likely only a matter of time before systemd
>  fillers through to them) various programs install jobs into /etc/cron.d
>  a quick look on one machine shows; mailman and sysstat related jobs as
>  well as some others...
>  
>  > those as normal timer-triggerd units inside of systemd itself (and
>  > get all the features it offers you for free, nice introspection,
>  > logging, IO/CPU scheduling hooks, yadda yadda). So, if you remove
>  > that /etc/crontab is empty and hence could be removed.
>  > And /etc/cron.d is empty too. And there you go, we can support cron
>  
>  Although I can't be the only one who puts various cron jobs
>  under /etc/cron.d that get run at various times. 
Yes, of course, people use those dirs. But by default they are
empty. And by using the systemd .path units we can make cron start the
moment somebody (or rpm) drops something into those dirs.

So, cron continues to work how it always worked! But the laptop
population won't have to run crond or at anymore. But they can still use
it, and it will just work, because the daemons are started the moment
they are needed.

So, drop your defensive reflexes: I am not taking anything away from
you. Just minimizing what we start in the default case. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Genes MailLists]

>  Although I can't be the only one who puts various cron jobs
>  under /etc/cron.d that get run at various times.
>  
>  Andrew 
 Almost every administrative cron here is in a cron.d crontab file .. we
need control over exactly what time certain things happen. So please
keep the functionality.


 If systemd is the expert spawner - then perhaps things like cron (or
any reproductive daemon for that matter) could lean on a systemd for
spawn service - but leave the other application specific parts to the
local daemons to do for themselves.

 There is some merit in functional separation too ...


  g

[Lennart Poettering]

On Thu, 25.11.10 19:57, Genes MailLists (lists(a)sapience.com) wrote:

>  
>  
>  > Although I can't be the only one who puts various cron jobs
>  > under /etc/cron.d that get run at various times.
>  > 
>  > Andrew
>  
>   Almost every administrative cron here is in a cron.d crontab file .. we
>  need control over exactly what time certain things happen. So please
>  keep the functionality. 
Hey, as I made explcitily clear I have no plans of taking away anything
from you. No need to be defensive...

>   If systemd is the expert spawner - then perhaps things like cron
> (or
>  any reproductive daemon for that matter) could lean on a systemd for
>  spawn service - but leave the other application specific parts to the
>  local daemons to do for themselves.
>  
>   There is some merit in functional separation too ... 
Well, there isn't if the remaining bits simply do some minimal calendar
calculations and do that in a way we shouldn't do things anymore, and
hence needs to be fixed anyway.

As mentioned: i have no plans to take crond away. Just change it to be
started a little bit differently.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Genes MailLists]

On 11/25/2010 09:08 PM, Lennart Poettering wrote:
>  On Thu, 25.11.10 19:57, Genes MailLists (lists(a)sapience.com) wrote:
keep the functionality.
>  
>  Hey, as I made explcitily clear I have no plans of taking away anything
>  from you. No need to be defensive... 
  Actually that was after I posted but ok :-) good!

> >  There is some merit in functional separation too ...
>  
>  Well, there isn't if the remaining bits simply do some minimal calendar
>  calculations and do that in a way we shouldn't do things anymore, and
>  hence needs to be fixed anyway. 

  mmm maybe ...

[Genes MailLists]

On 11/25/2010 09:19 PM, Genes MailLists wrote:
>  On 11/25/2010 09:08 PM, Lennart Poettering wrote:
> > On Thu, 25.11.10 19:57, Genes MailLists (lists(a)sapience.com) wrote:
>  keep the functionality.
> >
> > Hey, as I made explcitily clear I have no plans of taking away anything
> > from you. No need to be defensive...
>   
  Also was not being defensive (or aggressive :-) - just politely asking
...

  thanks!

[Michał Piotrowski]

2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
>  On Wed, 24.11.10 13:59, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
>
> >
> > 2010/11/24 Tomasz Torcz <tomek(a)pipebreaker.pl&gt;:
> > > On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
> > >> 2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
> > >> > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> I would like to help with scripts conversion. IMO the conversion
> > >> >> action should be coordinated.
> > >> >>
> > >> >> Comments, thoughts?
> > >> >
> > >> > I would certainly welcome any work in this direction!
> > >>
> > >> Could you look at the
> > >> crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
> > >> and
> > >> atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
> > >> and see if I did not do any fundamental error?
> > >>
> > >> Seems to me that these are simple enough at the beginning :)
> > >>
> > >> For both I used Type=forking - it works fine, but it seems to me that
> > >> Type=simple might be a better choice.
> > >
> > >  For type=simple you would like "-n" switch in crond invocation.
> >
> > Ah, ok, I'll keep forking.
>
>  It's generally nicer to use "simple" wherever possible, unless you have
>  a really good reason to assume that your service might be needed to be
>  up by something else, and that something else might want synchronize to
>  it. Since at/cron don't really offer any live protocols to other
>  processes I think Type=simple is a good idea here. 
Ok

I checked your atd.service and crond.service and voted for them in
617320 and 617324

>  BTW, regarding at and cron: what I was thinking of but never check
>  ehwther it is feasible is to make cron/at autostart a soon as some job
>  is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  user jobs exist, and start cron only then. Similarly for at. That way we
>  could support cron and at just fine, and wouldn't even have to run it by
>  default. I haven't looked into this in detail however, to see if the
>  file triggers systemd offers in .path units are already sufficient to
>  make this work. 
IMHO good idea. It should look something like this
ListenStream=/etc/cron.hourly/*
ListenStream=/etc/cron.daily/*
ListenStream=/etc/cron.weekly/*
ListenStream=/etc/cron.monthly/*
(more or less)

>  (And /etc/cron.daily and stuff would then be managed by systemd
>  natively, in a .timer unit)
>
> > > I suggest trimming Description, it is printed during bootup and should be
> short.
> >
> > I didn't noticed it - I guess "quiet" kernel param is also interpreted
> > by SystemD.
>
>  Yes, systemd honours "quiet":
>
>  Btw, it's written "systemd", not "SystemD". I even added a
> section about
>  the spelling now to the systemd homepage ;-) 
I have not read all the documentation yet ;)

>  Lennart
>
>  --
>  Lennart Poettering - Red Hat, Inc.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
Best regards,
Michal

[Lennart Poettering]

On Wed, 24.11.10 21:25, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:

>  > BTW, regarding at and cron: what I was thinking of but never
> check
>  > ehwther it is feasible is to make cron/at autostart a soon as some job
>  > is scheduled. I.e. use .path trigger to check whether /etc/crontab and
>  > user jobs exist, and start cron only then. Similarly for at. That way we
>  > could support cron and at just fine, and wouldn't even have to run it by
>  > default. I haven't looked into this in detail however, to see if the
>  > file triggers systemd offers in .path units are already sufficient to
>  > make this work.
>  
>  IMHO good idea. It should look something like this
>  ListenStream=/etc/cron.hourly/*
>  ListenStream=/etc/cron.daily/*
>  ListenStream=/etc/cron.weekly/*
>  ListenStream=/etc/cron.monthly/*
>  (more or less) 
(As mentioned elsewhere, DirectoryNotEmpty= is the right option here)

I think /etc/cron.{hourly, daily, weelkly, monthtly}/ should be handled
by a systemd timer, instead of a cron job in future. After all they
aren't handle by cron really either these days, but indirectly via run-parts.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Marcela Mašláňová]

On 11/24/2010 01:41 PM, Michał Piotrowski wrote:
>  2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
> > On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
> >
> >> Hi,
> >>
> >> I would like to help with scripts conversion. IMO the conversion
> >> action should be coordinated.
> >>
> >> Comments, thoughts?
> > I would certainly welcome any work in this direction!
>  Could you look at the
>  crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
>  and
>  atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
>  and see if I did not do any fundamental error?
>
>  Seems to me that these are simple enough at the beginning :)
>
>  For both I used Type=forking - it works fine, but it seems to me that
>  Type=simple might be a better choice.
>
>  Best regards,
>  Michal 
Could you explain, what's the difference between
https://bugzilla.redhat.com/show_bug.cgi?id=656864 and
https://bugzilla.redhat.com/show_bug.cgi?id=617324 ?

In the older bug was the correct script at least discussed. Why are you
mass opening new bugs, when the old weren't solved and they could contain
reasonable information as in this case?

Marcela

-- 
Marcela Mašláňová
BaseOS team Brno

[Michał Piotrowski]

2010/11/24 Marcela Mašláňová <mmaslano(a)redhat.com&gt;:
>  On 11/24/2010 01:41 PM, Michał Piotrowski wrote:
> > 2010/11/24 Lennart Poettering <mzerqung(a)0pointer.de&gt;:
> >> On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4(a)gmail.com) wrote:
> >>
> >>> Hi,
> >>>
> >>> I would like to help with scripts conversion. IMO the conversion
> >>> action should be coordinated.
> >>>
> >>> Comments, thoughts?
> >> I would certainly welcome any work in this direction!
> > Could you look at the
> > crond.service https://bugzilla.redhat.com/show_bug.cgi?id=656864
> > and
> > atd.service https://bugzilla.redhat.com/show_bug.cgi?id=656869
> > and see if I did not do any fundamental error?
> >
> > Seems to me that these are simple enough at the beginning :)
> >
> > For both I used Type=forking - it works fine, but it seems to me that
> > Type=simple might be a better choice.
> >
> > Best regards,
> > Michal
>  Could you explain, what's the difference between
>  https://bugzilla.redhat.com/show_bug.cgi?id=656864 and
>  https://bugzilla.redhat.com/show_bug.cgi?id=617324 ?
>
>  In the older bug was the correct script at least discussed. Why are you
>  mass opening new bugs, when the old weren't solved and they could contain
>  reasonable information as in this case? 
Sorry, I was not aware that Jóhann opened bugs for all this scripts.

>  Marcela
>
>  --
>  Marcela Mašláňová
>  BaseOS team Brno
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
Regards,
Michal

[Michał Piotrowski]

Hi,

What services are installed by default when installong form Live
GNOME/KDE/etc and DVD?

-- 
Best regards,
Michal

Sent from my iToaster

[Kevin Fenzi]

On Fri, 3 Dec 2010 09:14:26 +0100
Michał Piotrowski <mkkp4x4(a)gmail.com&gt; wrote:

>  Hi,
>  
>  What services are installed by default when installong form Live
>  GNOME/KDE/etc and DVD? 
Varies? :) 
I don't know that anyone has a list... it should be pretty easy to do
some installs and run 'chkconfig --list | grep 5:on'. Or did you mean
for f15? It's a bit early to tell, especially with systemd changes. 

kevin

[Michał Piotrowski]

2010/12/4 Kevin Fenzi <kevin(a)scrye.com&gt;:
>  On Fri, 3 Dec 2010 09:14:26 +0100
>  Michał Piotrowski <mkkp4x4(a)gmail.com&gt; wrote:
>
> > Hi,
> >
> > What services are installed by default when installong form Live
> > GNOME/KDE/etc and DVD?
>
>  Varies? :)
>  I don't know that anyone has a list... it should be pretty easy to do
>  some installs and run 'chkconfig --list | grep 5:on'. 
Yes, but unfortunately I have no way to install OS on VM and check -
my CPU lacks VMX, and I don't want to reinstall OS.

>  Or did you mean
>  for f15? 
Yes, actual nightly builds

>  It's a bit early to tell, especially with systemd changes.
It seems to me that conversion of all init scripts to native systemd
scripts might be impossible for F15 - work is not progressing rapidly
enough.

Currently I take the trivial targets. The next targets will be
services that I use in daily work - web apps related things.

Having a list of default services would be useful when choosing the
next conversion targets. Would be nice to have all init scripts for
commonly used things converted to systemd.

>  kevin
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  


-- 
Best regards,
Michal

Sent from my iToaster