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-23-2010, 11:29 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

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

>
> W dniu 23 listopada 2010 18:35 użytkownik philippe makowski
> <makowski.fedora@gmail.com> napisał:
> > 2010/11/23 Michał Piotrowski <mkkp4x4@gmail.com>:
> >> 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.
> > 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 07:07 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

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

>
> 2010/11/24 Tomasz Torcz <tomek@pipebreaker.pl>:
> > On Wed, Nov 24, 2010 at 01:41:49PM +0100, Michał Piotrowski wrote:
> >> 2010/11/24 Lennart Poettering <mzerqung@0pointer.de>:
> >> > 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!
> >>
> >> 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 07:56 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

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.

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:57 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

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

>
> 2010/11/24 Paul Wouters <paul@xelerance.com>:
> > 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 08:25 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Wed, 24.11.10 22:08, Michał Piotrowski (mkkp4x4@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 08:51 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Wed, 24.11.10 22:32, Michał Piotrowski (mkkp4x4@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-24-2010, 08:59 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Wed, 24.11.10 21:25, Michał Piotrowski (mkkp4x4@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 11-25-2010, 11:51 PM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Fri, 26.11.10 00:46, Andrew Clayton (andrew@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 12-24-2010, 10:13 AM
Lennart Poettering
 
Default F15 Feature - convert as many service init files as possible to the native SystemD services

On Fri, 26.11.10 16:18, Michał Piotrowski (mkkp4x4@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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 03:18 AM.

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