FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-24-2010, 12:09 AM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Sun, 21.11.10 00:46, Michał Piotrowski (mkkp4x4@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 07:29 PM
James Antill
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

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@gmail.com> wrote:
> > W dniu 21 listopada 2010 12:13 użytkownik Michał Piotrowski
> > <mkkp4x4@gmail.com> 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.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 06:39 AM
Tomas Mraz
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Wed, 2010-11-24 at 21:56 +0100, Lennart Poettering wrote:
> On Wed, 24.11.10 15:22, Paul Wouters (paul@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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 10:17 AM
Tomas Mraz
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote:
> 2010/11/25 Tomas Mraz <tmraz@redhat.com>:
> > 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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 03:33 PM
Tomas Mraz
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Thu, 2010-11-25 at 09:31 +0100, Michał Piotrowski wrote:
> 2010/11/25 Tomas Mraz <tmraz@redhat.com>:
> > 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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 11:15 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Thu, 25.11.10 08:39, Tomas Mraz (tmraz@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 11:27 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Thu, 25.11.10 17:33, Tomas Mraz (tmraz@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 12:03 AM
Miloslav Trmač
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

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.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 12:07 AM
Miloslav Trmač
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

Lennart Poettering p*še v Pá 26. 11. 2010 v 01:27 +0100:
> On Thu, 25.11.10 17:33, Tomas Mraz (tmraz@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

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-26-2010, 01:05 AM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Fri, 26.11.10 02:07, Miloslav Trmač (mitr@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@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 06:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org