Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using upstart scripts in packages #3027

Closed
kaso17 opened this issue Dec 3, 2017 · 6 comments
Closed

using upstart scripts in packages #3027

kaso17 opened this issue Dec 3, 2017 · 6 comments

Comments

@kaso17
Copy link

kaso17 commented Dec 3, 2017

Hi,

Since DSM 5 it seems like upstart is used as init system. By default the syno pkg installer generates a corresponding upstart config file /etc/init/pkgctl-$PACKAGE.conf.
Someone knows how the package can supply it's own upstart config (instead of the auto generated one) so we can make use of upstart features like automatic respwan?

https://neerajcodes.wordpress.com/2017/03/08/creating-a-package-for-synology-nas-device/ mentions that it can be done via the conf directory but no details on how to use it.
The official documentation doesn't mention this at all.
https://developer.synology.com/developer-guide/synology_package/conf.html

@ymartin59
Copy link
Contributor

I am curious to know why you are interested in writing your own upstart service configuration when Developer Guide explains how to provide a start-stop-status script: https://developer.synology.com/developer-guide/synology_package/scripts.html

For DSM 5 and 6 support, a new generic script will be soon available for package design:
https://github.com/SynoCommunity/spksrc/pull/2949/files#diff-9fe71615984368bf44c02ed52c3b1fce
Here is our reference documentation about it: https://github.com/SynoCommunity/spksrc/wiki/Service-Support#service-startup

So what are your needs requiring a specific upstart script for your package ?

@kaso17
Copy link
Author

kaso17 commented Dec 4, 2017

The primary reason is the respawn feature of upstart (automatic restart of the process in case the PID dies) and the simple logging.
I would like to update the jackett package init scripts, jackett uses it's own update mechanism (due to the very high release/update rate). The preferred way on linux is to use systemd/upstart to start it with automatic restarting enabled. Then the updater just replaces the files and kills the old process, systemd/upstart takes care of restarting it.
Without the init system restarting jackett the updater takes care of it (fork and restart the original command again).
With the updater instead of the init system restarting jackett the problems begins. The PID file doesn't get updated (not supported by jackett) breaking the stop/status feature (this can be fixed by using pidof or ps | grep to get the pid based on the program name). Besides that logging is a problem. logging is currently handled by the start-stop-status redirecting stdout/stderr. The jackett process/updater isn't aware of this. Due to this after an update logging is broken.

Besides that I'm not sure how logrotate is handled (is it handled at all?). You can't send a signal to reopen the stdout/stderr redirect so you've to use a copy/truncate solution which is bad for performance and you can loose log entries.

With a direct upstart script instead of the ductape solution via a traditional start-stop-status wrapper script all of these problems would be gone.

@ymartin59
Copy link
Contributor

As a package maintainer, problems go away when you keep thinks simple. From my point of view, a package is designed to install application in a specific version... or else it is almost impossible to reproduce, diagnose or provide support.
As far as I understand, disabling auto-update and self-restart is a first step. Then a wrapper script able to produce a PID file is another piece for the puzzle. As an example: https://github.com/SynoCommunity/spksrc/blob/dsm6/spk/demoservice/src/demoservice.sh

@kaso17
Copy link
Author

kaso17 commented Dec 7, 2017

Jackett is a little bit special due to it's high release frequency (multiple releases per week, sometimes even per day). Depending on the popularity of an indexer we get several duplicate issues if something breaks. That's why we decided to use the self updating mechanism instead of going through the various packaging systems.

I've already added PIDFile support and there's a pull request (#3032) to improve the syno init script.

Closing this issue as it seems like using direct upstart configs is simply not supported.

@kaso17 kaso17 closed this as completed Dec 7, 2017
@ymartin59
Copy link
Contributor

It may be possible, I have found following references:

I think conf directory mentioned is in a fact Synology SDK source structure to build package, and it may worth a trial to create a test case to investigate how SDK handle upstart script.

With current spksrc support, I would say installer script can be used to write service upstart configuration in /etc/init/ in preinst and remove it in preuninst.

@kaso17
Copy link
Author

kaso17 commented Dec 9, 2017

I had brief access to a DSM 6.1 box, no I no longer have access to test this.
From what I saw/remember the pkg installer generates an upstart conf file which calls the synopkgctl command which then used the start-stop-status script. The start/stop/status/log information of the synology package center also seems to bypass upstart and only relies on synopkgctl/start-stop-status script. The preinst workaround to overwrite the generated upstart file probably would work but I'm not sure how long they would survive (Do they get regenerated in future DSM releases?). Besides that for package manger compatibility it's probably necessary to still provide an start-stop-status script which then calls upstart/initctl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants