Bug 834918 - Provide native systemd service
Summary: Provide native systemd service
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: zarafa
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2012-06-24 21:58 UTC by Jóhann B. Guðmundsson
Modified: 2016-12-20 12:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-20 12:14:15 UTC


Attachments (Terms of Use)
Native systemd service file for zarafa-spooler (359 bytes, text/plain)
2012-06-24 22:00 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for zarafa-server (382 bytes, text/plain)
2012-06-24 22:00 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for zarafa-monitor (371 bytes, text/plain)
2012-06-24 22:02 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for zarafa-ical service (359 bytes, text/plain)
2012-06-24 22:02 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for zarafa-gateway (375 bytes, text/plain)
2012-06-24 22:03 UTC, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for zarafa-dagent (368 bytes, text/plain)
2012-06-24 22:04 UTC, Jóhann B. Guðmundsson
no flags Details

Description Jóhann B. Guðmundsson 2012-06-24 21:58:40 UTC
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:

Comment 1 Jóhann B. Guðmundsson 2012-06-24 22:00:10 UTC
Created attachment 594055 [details]
Native systemd service file for zarafa-spooler

Comment 2 Jóhann B. Guðmundsson 2012-06-24 22:00:59 UTC
Created attachment 594056 [details]
Native systemd service file for zarafa-server

Comment 3 Jóhann B. Guðmundsson 2012-06-24 22:02:00 UTC
Created attachment 594057 [details]
Native systemd service file for zarafa-monitor

Comment 4 Jóhann B. Guðmundsson 2012-06-24 22:02:35 UTC
Created attachment 594058 [details]
Native systemd service file for zarafa-ical service

Comment 5 Jóhann B. Guðmundsson 2012-06-24 22:03:25 UTC
Created attachment 594059 [details]
Native systemd service file for zarafa-gateway

Comment 6 Jóhann B. Guðmundsson 2012-06-24 22:04:47 UTC
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

Comment 7 Robert Scheck 2012-06-24 22:18:10 UTC
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.

Comment 8 Robert Scheck 2012-06-24 22:20:20 UTC
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.

Comment 9 Jóhann B. Guðmundsson 2012-06-24 22:32:21 UTC
(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?

Comment 10 Jóhann B. Guðmundsson 2012-06-24 22:33:47 UTC
(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

Comment 11 Jóhann B. Guðmundsson 2012-06-24 22:43:57 UTC
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.

Comment 12 Robert Scheck 2012-06-24 23:04:05 UTC
(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)...

Comment 13 Jóhann B. Guðmundsson 2012-06-24 23:26:55 UTC
(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

Comment 14 Robert Scheck 2012-06-24 23:49:18 UTC
(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?

Comment 15 Jóhann B. Guðmundsson 2012-06-25 00:14:21 UTC
(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

Comment 16 Fedora End Of Life 2013-04-03 17:18:49 UTC
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

Comment 17 Fedora Admin XMLRPC Client 2014-12-07 19:00:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 18 Jan Kurik 2015-07-15 15:07:08 UTC
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

Comment 19 Fedora End Of Life 2016-11-24 10:40:50 UTC
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.

Comment 20 Fedora End Of Life 2016-12-20 12:14:15 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.