Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 594055 [details] Native systemd service file for zarafa-spooler
Created attachment 594056 [details] Native systemd service file for zarafa-server
Created attachment 594057 [details] Native systemd service file for zarafa-monitor
Created attachment 594058 [details] Native systemd service file for zarafa-ical service
Created attachment 594059 [details] Native systemd service file for zarafa-gateway
Created attachment 594060 [details] Native systemd service file for zarafa-dagent These units are distro agnostic and should be usable across distribution using systemd thus acceptable by upstream
Hmm...thanks for providing, but I'm not really happy with the result, because: a) How will be /etc/sysconfig/zarafa or a possible replacement handled? Note, that this file is also parsed by non-initscripts during run-time b) Wants/After options - are they hard dependencies or soft ones? All these Zarafa services can run on different machines, means MySQL or Postfix do not necessarily have to run on the same machine, even they do normally. c) /tmp/zarafa-upgrade-lock is not handled at all, but it should be. d) There is no timeout feature in the stopping of zarafa-server anymore. e) "Type=forking" is nice, but you can configure the Zarafa services within the configuration file to use threading instead of forking. How does this play together with systemd then? In order to get these files upstream, the upstream contributor agreement needs to be signed first as well. Alternatively I could offer some proxyfying, but then the contribution is no longer under your name.
AFAIK systemd also provides handling of TCP ports and Unix sockets, but I am not knowledged enough with systemd to figure out if this could be mixed with the Zarafa services somehow.
(In reply to comment #7) > Hmm...thanks for providing, but I'm not really happy with the result, > because: > > a) How will be /etc/sysconfig/zarafa or a possible replacement handled? Note, > that this file is also parsed by non-initscripts during run-time /etc/sysconfig/zarafa is fedora specific hows this handle by upstream by default? Administrators should be following this when modifying daemon/service instead of using /etc/sysconfig/foo files https://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F > b) Wants/After options - are they hard dependencies or soft ones? All these > Zarafa services can run on different machines, means MySQL or Postfix do > not necessarily have to run on the same machine, even they do normally. Want's are soft dependency ( Requires are hard ) so if the service exist it will be started if not it wont > c) /tmp/zarafa-upgrade-lock is not handled at all, but it should be. Hmm not sure how we should proceed here perhaps introduce specific zarafa-upgrade unit? > d) There is no timeout feature in the stopping of zarafa-server anymore. ? TimeoutSec should handle that, > e) "Type=forking" is nice, but you can configure the Zarafa services within > the configuration file to use threading instead of forking. How does this > play together with systemd then? You would have to modify the units to handle this or provide additional set of units that do this > In order to get these files upstream, the upstream contributor agreement > needs > to be signed first as well. Alternatively I could offer some proxyfying, but > then the contribution is no longer under your name. Got a link to that contribution/joining agreement for upstream?
(In reply to comment #8) > AFAIK systemd also provides handling of TCP ports and Unix sockets, but I am > not knowledged enough with systemd to figure out if this could be mixed with > the Zarafa services somehow. You can ship both socket activated and regular units worst case scenario you might need provide alternative names for units activated by the socket
hmm We could call an script to handle the upgrade-lock via Execstop= or handle upgrades if applicable before the service is started via ExecStartPre= anyway just add those units to /etc/systemd/system directory then run systemctl daemon-reload and systemctl start/stop/restart zarafa-foo.service to test the units so we can iron out any remaining issues.
(In reply to comment #9) > /etc/sysconfig/zarafa is fedora specific hows this handle by upstream by > default? http://doc.zarafa.com/trunk/Administrator_Manual/en-US/html/_configure_language.html If /etc/default is better, then systemd needs to read that file, because it does not make sense to have the administrator editing all systemd foo files. > > c) /tmp/zarafa-upgrade-lock is not handled at all, but it should be. > > Hmm not sure how we should proceed here perhaps introduce specific > zarafa-upgrade unit? Finally, the zarafa-server process never should be stopped if there is an internal database upgrade running. If you stop zarafa-server, it will eat your complete database. As RHEL 7 will also use that systemd foo, we need really a good solution for this. > > e) "Type=forking" is nice, but you can configure the Zarafa services within > > the configuration file to use threading instead of forking. How does this > > play together with systemd then? > > You would have to modify the units to handle this or provide additional set > of units that do this That sucks, sorry. Switching the configuration file and changing the systemd foo at the same time to get rid of this is really loosing flexibility now by using systemd rather initscripts. Ideas? > Got a link to that contribution/joining agreement for upstream? http://community.zarafa.com/download/Zarafa_Contribution_Agreement_fillable.pdf should be filled, signed and sent to them either via fax, scanned or postal. (In reply to comment #11) > hmm We could call an script to handle the upgrade-lock via Execstop= or > handle upgrades if applicable before the service is started via > ExecStartPre= anyway just add those units to /etc/systemd/system directory > then run systemctl daemon-reload and systemctl start/stop/restart > zarafa-foo.service to test the units so we can iron out any remaining issues. As written above, once the upgrade is running any stop of the zarafa-server must be avoided otherwise your database will be likely unusable. What we can use is /tmp/zarafa-upgrade-lock, because it is created by the zarafa-server process as long as a database upgrade is running (and removed afterwards)...
(In reply to comment #12) > (In reply to comment #9) > > /etc/sysconfig/zarafa is fedora specific hows this handle by upstream by > > default? > > http://doc.zarafa.com/trunk/Administrator_Manual/en-US/html/ > _configure_language.html > > If /etc/default is better, then systemd needs to read that file, because it > does not make sense to have the administrator editing all systemd foo files. Hmm I think /etc/default is actually debian system specific so it just becomes a question if that environment file should not just be moved into the /etc/zarafa directory and we add "EnvironmentFile=-/etc/zarafa/zarafa" and change the Environments entries to LC_ALL=$ZARAFA_LOCA LANG=$ZARAFA_LOCALE instead in all units? > > > > c) /tmp/zarafa-upgrade-lock is not handled at all, but it should be. > > > > Hmm not sure how we should proceed here perhaps introduce specific > > zarafa-upgrade unit? > > Finally, the zarafa-server process never should be stopped if there is an > internal database upgrade running. If you stop zarafa-server, it will eat > your complete database. As RHEL 7 will also use that systemd foo, we need > really a good solution for this. You will need to provide me with better information on how the upgrade(s) take place in zafara since I'm not familiar with it but most likely we will need to call a script that checks this via ExecStop= line and add that to the relevant units. Probably it should be enough to create a file that contains ### zarafa-check-if-upgrading ### #!/usr/bin/bash if [ -f /tmp/zarafa-upgrade-lock ]; then echo echo "Zarafa Server database upgrade is taking place." echo "Do not stop this process bacause it may render your database unusable." echo exit 1 fi Done or something similar > > > > e) "Type=forking" is nice, but you can configure the Zarafa services within > > > the configuration file to use threading instead of forking. How does this > > > play together with systemd then? > > > > You would have to modify the units to handle this or provide additional set > > of units that do this > > That sucks, sorry. Switching the configuration file and changing the systemd > foo at the same time to get rid of this is really loosing flexibility now by > using systemd rather initscripts. Ideas? Hmm have you actually tested if this is an issue? > > > Got a link to that contribution/joining agreement for upstream? > > http://community.zarafa.com/download/Zarafa_Contribution_Agreement_fillable. > pdf > should be filled, signed and sent to them either via fax, scanned or postal. Really via fax,scanned or postal nothing online? > > (In reply to comment #11) > > hmm We could call an script to handle the upgrade-lock via Execstop= or > > handle upgrades if applicable before the service is started via > > ExecStartPre= anyway just add those units to /etc/systemd/system directory > > then run systemctl daemon-reload and systemctl start/stop/restart > > zarafa-foo.service to test the units so we can iron out any remaining issues. > > As written above, once the upgrade is running any stop of the zarafa-server > must be avoided otherwise your database will be likely unusable. What we can > use is /tmp/zarafa-upgrade-lock, because it is created by the zarafa-server > process as long as a database upgrade is running (and removed afterwards)... yeah I think we can handle that via ExecStop= and a script
(In reply to comment #13) > Hmm I think /etc/default is actually debian system specific so it just > becomes a question if that environment file should not just be moved into > the /etc/zarafa directory and we add "EnvironmentFile=-/etc/zarafa/zarafa" > and change the Environments entries to LC_ALL=$ZARAFA_LOCA > LANG=$ZARAFA_LOCALE instead in all units? When looking to /etc/default, it does not look that Debian specific on a recent Fedora 17. Even glibc seems to use it for ages now (aside of grub2). However EnvironmentFile seems to be suitable in general, if I get it right. AFAIK there is no guideline about /etc/default, there just was recently a discussion on one of our mailing lists when googling for /etc/default. > Hmm have you actually tested if this is an issue? No, I did not yet play with threading inside of Zarafa while Type=forking in systemd... > Really via fax,scanned or postal nothing online? Yes, that's how it works. Scanned and sent via e-mail is the most online one that you can get. > yeah I think we can handle that via ExecStop= and a script Where whould such a helper script go into? /usr/libexec?
(In reply to comment #14) > (In reply to comment #13) > > Hmm I think /etc/default is actually debian system specific so it just > > becomes a question if that environment file should not just be moved into > > the /etc/zarafa directory and we add "EnvironmentFile=-/etc/zarafa/zarafa" > > and change the Environments entries to LC_ALL=$ZARAFA_LOCA > > LANG=$ZARAFA_LOCALE instead in all units? > > When looking to /etc/default, it does not look that Debian specific on a > recent Fedora 17. Even glibc seems to use it for ages now (aside of grub2). > However EnvironmentFile seems to be suitable in general, if I get it right. > AFAIK there is no guideline about /etc/default, there just was recently a > discussion on one of our mailing lists when googling for /etc/default. You can see a bit of history about this stuff here [1] > > Hmm have you actually tested if this is an issue? > > No, I did not yet play with threading inside of Zarafa while Type=forking in > systemd... > > > Really via fax,scanned or postal nothing online? > > Yes, that's how it works. Scanned and sent via e-mail is the most online one > that you can get. Hmm ok then it's probably best that you just submit the units via your account once we have ironed all the issues out. > > yeah I think we can handle that via ExecStop= and a script > > Where whould such a helper script go into? /usr/libexec? Yup so with all the the mentioned changes the zarafa-server.service unit to test should look something like this... [Unit] Description=Zarafa Collaboration Platform's Storage Server Documentation=man:zarafa-server(1) man:zarafa-server.cfg(5) man:zarafa-admin(1) Wants=mysqld.service After=network.target mysqld.service [Service] Type=forking GuessMainPID=no EnvironmentFile=-/etc/zarafa/zarafa # or /etc/sysconfig/zarafa or /etc/default/zarafa Environment=LC_ALL=$ZARAFA_LOCALE LANG=$ZARAFA_LOCALE ExecStart=/usr/bin/zarafa-server -c /etc/zarafa/server.cfg ExecStop=/usr/libexec/zarafa-check-if-upgrading TimeoutSec=65 [Install] WantedBy=multi-user.target And if working and acceptable we can add the environment changes to the other units as well. 1.http://0pointer.de/blog/projects/on-etc-sysinit.html
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.