F15 Feature - convert as many service init files as possible to the native SystemD services
Hi,
I would like to help with scripts conversion. IMO the conversion action should be coordinated.
Comments, thoughts?
Kind regards, Michal
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.
2010/11/21 Ville Skyttä ville.skytta@iki.fi:
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
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?
Best regards, Michal
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.
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.
2010/11/23 Jason L Tibbitts III tibbs@math.uh.edu:
"MP" == Michał Piotrowski mkkp4x4@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Michał Piotrowski (mkkp4x4@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
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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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/*
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 ?
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)
Best regards, Michal
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
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
2010/11/23 "Jóhann B. Guðmundsson" johannbg@gmail.com:
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Best regards, Michal
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
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.
Best regards, Michal
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. I suggest trimming Description, it is printed during bootup and should be short.
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.
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@chrome.pl an IP-routable hand grenade.'' -- Andrew Morton (LKML)
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kind regards, Michal
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
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
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)
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kind regards, Michal
On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski 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)
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 ;)
W dniu 24 listopada 2010 21:34 użytkownik Tomasz Torcz tomek@pipebreaker.pl napisał:
On Wed, Nov 24, 2010 at 09:30:03PM +0100, Michał Piotrowski 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)
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@chrome.pl "God is more forgiving."
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
Someone uses cherokee web server? Please check this service https://bugzilla.redhat.com/show_bug.cgi?id=657085
Kind regards, Michal
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
2010/11/24 Lennart Poettering mzerqung@0pointer.de:
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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kind regards, Michal
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
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
2010/11/24 Lennart Poettering mzerqung@0pointer.de:
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?
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Best regards, Michal
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
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.
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 :)
Kind regards, Michal
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. :)
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.
W dniu 25 listopada 2010 17:33 użytkownik Tomas Mraz tmraz@redhat.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Best regards, Michal
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 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.
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
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 píše v Pá 26. 11. 2010 v 03:05 +0100:
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.
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
Miloslav =?UTF-8?Q?Trma=C4=8D?= mitr@volny.cz 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
Once upon a time, Lennart Poettering mzerqung@0pointer.de 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.
On 11/25/2010 11:01 PM, Chris Adams wrote:
Once upon a time, Lennart Poettering mzerqung@0pointer.de 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 ...
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@0pointer.de 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
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
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?
2010/11/26 Tomasz Torcz tomek@pipebreaker.pl:
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@chrome.pl -- Mitchell Blank on LKML
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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
On Fri, 2010-11-26 at 03:05 +0100, Lennart Poettering wrote:
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.
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.
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@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
On 11/26/2010 01:27 AM, Lennart Poettering wrote:
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.
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
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?!
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
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
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
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
On Thu, 25.11.10 19:57, Genes MailLists (lists@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
On 11/25/2010 09:08 PM, Lennart Poettering wrote:
On Thu, 25.11.10 19:57, Genes MailLists (lists@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 ...
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@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!
2010/11/24 Lennart Poettering mzerqung@0pointer.de:
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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Best regards, Michal
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
On 11/24/2010 01:41 PM, 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.
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
2010/11/24 Marcela Mašláňová mmaslano@redhat.com:
On 11/24/2010 01:41 PM, 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.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Regards, Michal
Hi,
What services are installed by default when installong form Live GNOME/KDE/etc and DVD?
On Fri, 3 Dec 2010 09:14:26 +0100 Michał Piotrowski mkkp4x4@gmail.com 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
2010/12/4 Kevin Fenzi kevin@scrye.com:
On Fri, 3 Dec 2010 09:14:26 +0100 Michał Piotrowski mkkp4x4@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Andrew Clayton -
Bill Nottingham -
Bruno Wolff III -
Chris Adams -
Frank Ch. Eigler -
Genes MailLists -
James Antill -
Jason L Tibbitts III -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Lennart Poettering -
Marcela Mašláňová -
Michal Schmidt -
Michał Piotrowski -
Miloslav Trmač -
Paul Wouters -
Philippe Makowski -
Rudolf Kastl -
Tomas Mraz -
Tomasz Torcz -
Ville Skyttä