Bug 772034 - Provide native systemd service
Summary: Provide native systemd service
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ctdb
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Sumit Bose
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 751869
TreeView+ depends on / blocked
 
Reported: 2012-01-05 17:43 UTC by Jóhann B. Guðmundsson
Modified: 2013-12-11 11:50 UTC (History)
5 users (show)

Fixed In Version: ctdb-2.4-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-11 11:50:51 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Native systemd service file for ctdb (181 bytes, text/plain)
2012-01-05 17:44 UTC, Jóhann B. Guðmundsson
no flags Details
Proposed files for systemd integration (950 bytes, application/x-bzip)
2012-01-10 10:53 UTC, Sumit Bose
no flags Details
Sample ctdb target (759 bytes, application/x-bzip)
2012-01-10 19:04 UTC, Jóhann B. Guðmundsson
no flags Details

Description Jóhann B. Guðmundsson 2012-01-05 17:43:03 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-01-05 17:44:11 UTC
Created attachment 550973 [details]
Native systemd service file for ctdb

Comment 2 Jóhann B. Guðmundsson 2012-01-05 17:45:34 UTC
Let's start with the above unit file and work out any remaining issues. 

I think we can have systemd handle alot of these things that those scripts are doing.

Comment 3 Sumit Bose 2012-01-09 12:02:26 UTC
Thank you for the initial starter script. I will add some ExecStartPre and ExecStartPost to be compatible with the current SysV init script.

I currently do not know how to convert the functionality of build_ctdb_options() from the SysV init script. Currently ctdb uses key-value pairs in /etc/sysconfig/ctdb where the value does not contain the option name. E.g. there is only 'CTDB_RECOVERY_LOCK="/some/place/on/shared/storage"' but the ctdbd needs "--reclock /some/place/on/shared/storage" as a command line option at startup. So I think I can neither use EnvironmentFile because /etc/sysconfig/ctdb does not contains the needed values nor ExecStartPre because it cannot modify the environment.

Would it be allowed to a script with ExecStart which reads /etc/sysconfig/ctdb, call build_ctdb_options() and then calls 'exec /usr/sbin/ctdbd' with the generated command line arguments?

Comment 4 Jóhann B. Guðmundsson 2012-01-09 13:34:45 UTC
I'm not so sure you can be backward compatible with the legacy sysv init script for example custom status is out and using /etc/sysconfig/ctdb will not fly with upstream since the solution needs to be distro agnostic as in the unit files in Fedora should be usable with OpenSuse,Arch,Gentoo and any other distribution that uses systemd as their init system and /etc/sysconfig/foo is Fedora/Red Hat specific.

If the user/admins needs to set some specific parameters the correct way of doing things now is to copy the unit to /etc/systemd/system directory and add those parameters to the unit there or create a new unit in that directory that contains .include and then any additional foo he wants to add to the unit.

From the looks of it the main problem here is that the daemon does not parse config file ( /usr/sbin/ctdbd -f /etc/ctdb/ctdb.conf ) where the administrator would set all those "maybe" or build options there 

And I'm pretty sure that the "functions" in the /etc/ctdb directory needs to be looked at/rewritten to use systemctl and all specific distribution bit can be removed from there as well and probably those shell script that reside in that directory should be in /usr/libexec/ctdb directory instead.

All of the above is the reason why I only posted a dry daemon unit because I dont have an clear picture of what's needed for a proper ctdb startup and depending on that it might be better to use oneshot units that are started before the daemon is started ( we would add Requires=ctdb-foo.unit and After=ctdb-foo.service to the ctdb.service ).

Comment 5 Sumit Bose 2012-01-10 10:53:17 UTC
Created attachment 551807 [details]
Proposed files for systemd integration

Comment 6 Sumit Bose 2012-01-10 10:54:14 UTC
/etc/sysconfig/ctdb is used by upstream as the configuration file for ctdb. 

Please have a look at the scripts in the attached tar ball. If this is acceptable form the systemd point-of-view I will talk to upstream and SUSE if they will use them too. I will also talk to upstream to see if it would be possible that ctdbd reads /etc/sysconfig/ctdb at startup before evaluating command line option. This way systemd would be able to start ctdbd directly and not with the ctdb.systemd. helper.

Comment 7 Jóhann B. Guðmundsson 2012-01-10 19:02:39 UTC
Note that "ulimit -c unlimited" ctdb.system might need to be put into the ctdb,service file as "LimitNOFILE=infinity" 

As in 

[Unit]
Description=CTDB
After=network.target

[Service]
Type=forking
LimitNOFILE=infinity
ExecStartPre=/etc/ctdb/systemd/ctdb_drop_all_public_ips
ExecStartPre=/etc/ctdb/systemd/ctdb_check_persistent_databases.pre
ExecStart=/etc/ctdb/systemd/ctdb.systemd
ExecStartPost=/etc/ctdb/systemd/ctdb_set_ctdb_variables.post
ExecStop=/usr/bin/ctdb shutdown
ExecStopPost=-/etc/ctdb/systemd/ctdb_drop_all_public_ips
KillMode=control-group
Restart=on-failure

[Install]
WantedBy=multi-user.target

We can also split the that unit into separated type oneshot units and bind those unit's to ctdb.service and introduce a specific ctdb.target it's more of a matter of taste see the attached file on how it might be done.

Comment 8 Jóhann B. Guðmundsson 2012-01-10 19:04:44 UTC
Created attachment 551916 [details]
Sample ctdb target

Comment 9 Jóhann B. Guðmundsson 2012-01-10 20:16:36 UTC
It would be could if you could add links to the upstream/opensuse discussion with regards to systemd on this bug report. 

Thanks

Comment 10 Jóhann B. Guðmundsson 2012-01-10 20:38:01 UTC
(In reply to comment #9)
> It would be could if you could add links to the upstream/opensuse discussion
> with regards to systemd on this bug report. 
> 
> Thanks

be could :|

s/be could/be good =)

Comment 11 Sumit Bose 2012-01-10 21:13:14 UTC
Thank you for the feedback. 

I think you mean LimitCORE instead of LimitNOFILE.

I will test your files and will send them to the samba-technical list to discuss them with upstream and SUSE. I will add a link to the archive here. 

Are there some docs which discuss when it would be preferred to use ExecStartPre/Post and when the oneshot unit or is it only taste?

Comment 12 Jóhann B. Guðmundsson 2012-01-10 23:02:43 UTC
(In reply to comment #11)
> Thank you for the feedback. 
> 
> I think you mean LimitCORE instead of LimitNOFILE.
> 

You are absolutely correct. 

I've gone so used to seeing the number of open file descriptors being increase/set to infinity in those legacy sysv init scripts I automatically took it as one when I came across the ulimit call.

> I will test your files and will send them to the samba-technical list to
> discuss them with upstream and SUSE. I will add a link to the archive here. 
> 
> Are there some docs which discuss when it would be preferred to use
> ExecStartPre/Post and when the oneshot unit or is it only taste?

We unfortunately dont have any official legacy sysv to systemd migration documentation since we kinda have needed to handle those legacy scripts on case by case bases and at the same time figure out what is the best way to solve that ( for the most part it turns out to be relatively simple but in other cases like with fds and the freeipa stack it can turn out to be a bit complex ). 

With regards to ExecStartPre and ExecStartPost here are the things you need to know 

systemd does not allow long running processes to be started in Pre and Post
sections. It's a bug that this is currently possible which is about to be fixed.

All individial services need to be started by individual service files to be
supervised by systemd. Alternatively, it can all be stared with by some
wrapper script, but that way, it will not be able to use any advanced feature
of systemd.

Newer versions of systemd ( F17+) will force-kill all remaining processes that are still running when the Pre and Post section are left during a unit start transaction.

With regards to ctdb.target I guess it all depends on which future direction ctdb takes with regarding ctdb service management and systemd ( if any ) and if it takes any advantages of what systemd has to offer ( that is if it offers ctdb any advantages ). 

If ctdb will be carrying it's own units for the service it manages for example then having ctdb.target could be very useful ( those unit would just be made to conflict with the native ones for samba apache etc and would be tied to the ctdb.target as in [Install] WantedBy=ctdb.target ).

Or if you want to boot into a specific ctdb.targets which setups and runs everything for ctdb deployment it's useful.

However if ctdb wants to speak to a separate daemon over the network which would handle auth for that and d-bus interaction or use dbus-over-ssh which is already available ( systemd natively just needs a dbus-patch, that is ready to merge to provide that I believe ) for service management and use existing units or existing solution using a target gain you little benefit. 

I think Lennart and Kay promised that working for rhel cluster management stuff so solution to do something like the ( dbus ) stuff above should be working someday.

Unfortunately I'm not familiar with ctdb and never used in a production environment and thus I provide very limited input on what's the best way to proceed forward with this.

Comment 13 Jóhann B. Guðmundsson 2012-08-02 16:38:37 UTC
So now what roughly six months later what came out of the discussion with upstream and suse crew?

Comment 14 Fedora End Of Life 2013-04-03 17:32:23 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 15 Sumit Bose 2013-12-11 11:50:51 UTC
Native systemd support is available with ctdb-2.4. Fixed with ctdb-2.4-1.fc20


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