Service Doesn't Support Chkconfig

Service php-fpm does not support chkconfig

Is there a php-fpm script in /etc/init.d? That's what chkconfig works off of. It looks for a comment in the script:

 # chkconfig: 345 26 74

to figure out which runlevels should be configured. If there's no php-fpm init script, or the script doesn't contain that chkconfig comment, then chkconfig has nothing to work off of.

How do I install chkconfig on Ubuntu?

The command chkconfig is no longer available in Ubuntu.The equivalent command to chkconfig is update-rc.d.This command nearly supports all the new versions of ubuntu.

The similar commands are

update-rc.d <service> defaults

update-rc.d <service> start 20 3 4 5

update-rc.d -f <service>  remove

Puppet does not add my service to start up

The issue is probably the provider => init line, which is overriding the default provider for handling services. The init provider is a very simple provider that doesn't support the "enableable" feature, so it can't set a service to start on boot.

See http://docs.puppetlabs.com/references/2.7.6/type.html#service for its capabilities.

In your puppet apply example, you don't specify the provider so it picks the most appropriate for your system - in your case the "redhat" provider that uses chkconfig.

To fix this, remove the provider line from your service {} definition and it will again default to the most appropriate. You only need to specify a provider if it picks incorrectly and then it's best to specify it as a global default.

Linux daemon start up

Put 2 comments into your script:

# chkconfig: - 90 10
# description: description of your service

As root, run :

chkconfig --add my_service

run solr like daemon

This isn't working because the daemon function (from /etc/init.d/functions) has changed since 2010 (when the script was posted) and no longer accepts the same arguments. You will need to rewrite the daemon line to accept the currently supported arguments.

I had a look at the daemon function on a CentOS 6 box, and it looks like you might be able to replace this line:

daemon --chdir='/usr/local/solr/example' --command "java -jar start.jar" --respawn --output=/var/log/solr/solr.log --name=solr --verbose

with just this:

daemon "java -jar /usr/local/solr/example/start.jar"

(assuming that solr is installed in /usr/local/solr/example).

Create systemd service in AWS Elastic Beanstalk on new Amazon Linux 2

systemd is not supported in Services. The only correct is sysvinit:

services:
  sysvinit:
    my_worker:
      enabled: "true"
      ensureRunning: "true"

But I don't think it will even work, as this is for Amazon Linux 1, not for Amazon Linux 2.

In Amazon Linux 2 you shouldn't be even using much of .ebextensions. AWS docs specifically write:

On Amazon Linux 2 platforms, instead of providing files and commands in .ebextensions configuration files, we highly recommend that you use Buildfile. Procfile, and platform hooks whenever possible to configure and run custom code on your environment instances during instance provisioning.

Thus, you should consider using Procfile which does basically what you want to achieve:

Use a Procfile for long-running application processes that shouldn't exit. Elastic Beanstalk expects processes run from the Procfile to run continuously. Elastic Beanstalk monitors these processes and restarts any process that terminates. For short-running processes, use a Buildfile.

Alternative

Since you already have created a unit file /etc/systemd/system/my_worker.service for systemd, you can enable and start it yourself.

For this container_commands in .ebextensions can be used. For example:

container_commands:
   10_enable_worker:
     command: systemctl enable worker.service
   20_start_worker:
     command: systemctl start worker.service