How to use systemd to enable service at booting automatically ?

[User808]

Hi.
If I install a service (a local package installation), & this service not started automatically at system boot, & I like to make it start automatically at system boot, so:

1) how can I achieve this by using systemd ?

2) and are there parameters to make it's automatic start up delayed in relation to other specific automatically started service ?

Best.

[lsatenstein]

You might want to look at crontab and the @reboot parameter as a first method.

[donatom]

Try "# systemctl enable name-of-service" and then "# systemctl start name-of-service". This is how you usually start a service automatically at boot. If you want to control when the service is active only use "# systemctl start (or restart) name-of-service"

[dswaner]

are there parameters to make it's automatic start up delayed in relation to other specific automatically started service ?

It looks like what you want is:

# systemctl add-requires <target> <my-service>

or

# systemctl add-wants <target> <my-service>

[User808]

It looks like what you want is:

# systemctl add-requires <target> <my-service>

or

# systemctl add-wants <target> <my-service>

Hi. Thank you. Could you explain more please ? In my case I like to make ccp.d start automatically at boot BUT after cups already started at boot. So, is this dome by:

sudo systemctl add-requiries cups ccp.d
or
sudo systemctl add-wants cups ccp.d

Does "add-requiries" / "add-wants" should entered as it or it it should replaced by parameter ?

I have no previous experience with systemd commands.

[dswaner]

sudo systemctl add-requires ccpd cups.service

is my best guess. A requirement is attached to the ccpd service, namely the cups.service, so ccpd should start after cups.

CORRECTION:

A REQUIRES between two services is not the same as an AFTER. With a requires, both units start at the same time, or both fail.
And the ccpd isn't a service - ccpd should be started by a ccp.service. In short, I think you need someone who knows a lot more
about systemd than me.

A link that might be helpful, but not simple is: managing_services_with_systemd-unit_files

ADDITIONAL COMMENT:

You may want to just use rc.local, and forget about systemd. Just put the starting of ccpd in /etc/rc.d/rc.local, and it will be started automatically
(just like before systemd). rc.local is one of the last services to be started, so cups should already be running.

[dswaner]

I successfully (mostly) changed an /etc/rc.d/rc.local initialization script to a systemd service:

created /etc/systemd/system/local_init.service:

[Unit]
Description=Local Init Service
After=rc-local.service

[Service]
ExecStart=/usr/local/bin/local_init.sh
StandardOutput=syslog
StandardError=syslog

[Install]
WantedBy=multi-user.target

removed all my local init stuff from /etc/rc.d/rc.local

created /usr/local/bin/local_init.sh (essentially a clone of rc.local).

enabled local_init.service

rebooted. It works (mostly - all the bind mounts work; still having a problem with rxapi).

So, it seems like creating a ccp.service which specifies After=cups.service would work.

Additional comment:
Since ccpd is a daemon, you probably need to add
"RemainAfterExit=yes" before the ExecStart=

[srakitnican]

Hi.
If I install a service (a local package installation), & this service not started automatically at system boot, & I like to make it start automatically at system boot, so:

1) how can I achieve this by using systemd ?

2) and are there parameters to make it's automatic start up delayed in relation to other specific automatically started service ?

Best.

With systemd you would want either a service to start, or to be started automatically whenever something else requires it. A service may start based on socket activation, example for this sshd.socket, which starts automatically whenever someone tries to connect to ssh server but is not running by default.

There is also a third way, that is timer functionality that resembles crontab for services that needs to do something at specific time interval. dnf-makecache.timer is an example for this.

You can take a look how services mentioned looks like in /usr/lib/systemd/system/ . See also `man systemd.unit` , `man systemd.timer`, `man systemd.socket` etc.

[dswaner]

@User808:
Rethinking you original question:
Hopefully a service came supplied with your ccpd package. If the service's location isn't documented,
try doing a "locate ccp". If you find the service, then make a symbolic link to it in /etc/systemd/system.
Then try to enable the service. If that works, then start the service.

However, if a service wasn't supplied with the package, then you need to create a custom one:

An example of a service, which probably is similar to what you want:

[Unit]
Description=ooRexx rxapi service
After=syslog.target
After=network.target

[Service]
Type=forking
PIDFile=/var/run/ooRexx.pid
ExecStartPre=/bin/rm -f /var/run/rxapid.pid
ExecStart=/usr/bin/rxapi
Restart=on-abort

[Install]
WantedBy=multi-user.target

This service appears to work OK. However, I think there may be some errors here. I believe
this daemon doesn't actually fork a child process, so the Type is wrong and maybe PIDFile isn't needed.
Perhaps these "errors" are needed to work around some bug?

CORRECTION:
I now believe that the rxapi does fork a child process, the Type is NOT wrong, and the PIDFile is good to have.
There isn't any "bug" here to work around - just my misunderstanding.

[User808]

@User808:
Rethinking you original question:
Hopefully a service came supplied with your ccpd package. If the service's location isn't documented,
try doing a "locate ccp". If you find the service, then make a symbolic link to it in /etc/systemd/system.
Then try to enable the service. If that works, then start the service.

However, if a service wasn't supplied with the package, then you need to create a custom one:

An example of a service, which probably is similar to what you want:

[Unit]
Description=ooRexx rxapi service
After=syslog.target
After=network.target

[Service]
Type=forking
PIDFile=/var/run/ooRexx.pid
ExecStartPre=/bin/rm -f /var/run/rxapid.pid
ExecStart=/usr/bin/rxapi
Restart=on-abort

[Install]
WantedBy=multi-user.target

This service appears to work OK. However, I think there may be some errors here. I believe
this daemon doesn't actually fork a child process, so the Type is wrong and maybe PIDFile isn't needed.
Perhaps these "errors" are needed to work around some bug?

Thank you for your efforts to help me.

My be the following assist in clearify picture:

1) sudo service ccpd start
will start ccpd via redirection to systemctl corresponding command.
So, in this case, does
sudo service ccpd enable
valid command ? It should be. I have to try it. But problem is that ccpd should start after cups already start. Again I have to try

2) you clearify something very important:
you inzagract to create:
/etc/rc.d/rc.local
but in official document of package it say /etc/rc.local but later say use following command:
sudo chmod 777 /etc/rc.d/rc.local
I think that there is mistake in official document because when I created /etc/rc.local then run "sudo chmod 777 /etc/rc.d/rc.local" I received "this file not found".
Now I have to retry with "etc/rc.d/rc.local" & see ...

3) in official document it say add following to rc.local:
#!/bin/sh
/etc/init.d/ccpd start

But when I tried "/etc/init.d/ccpd start" command (before creating etc/rc.d/rc.local" file) I got error & I only get ccpd start by "sudo service ccpd start" command which redirect me to systemctl command ..... .

So, what is your opinion about this (point 3) ? I think that there need for modifications fit for Fedora.

Best.

[dswaner]

The "/etc/init.d/ccpd start" is the old way of doing this, before systemd. Also rc.local is the old way, but it still
works - you would need to create a valid rc.local script. There used to be a default do-nothing rc.local script,
which you could modify, but that was eliminated not long ago, so you need to create rc.local now, if you are
going to use it. So the official documentation in some places it is talking about the old way of doing things.
Presumably you want to try to get the new way working - a systemd service.

[User808]

Hi. Issue solved after 2 year struggle !
ccpd NOT compitable with "sudo service ccpd enable". Only start | stop | status usage possible with ccpd if you use " sudo service ccpd ...."

On other hand "sudo vi /etc/rc.d/rc.local" then adding
#!/bin/sh
/etc/init.d/ccpd start
Then save & exit & finally use:
sudo chmod 777 /etc/rc.d/rc.local
& every thing will go O.K !

Now my Canon printer work better than my new hp printer ! My new hp printer need hp-plugin & this need re-installation every time hplip updated !

Wrong was from Canon that did not corrected error in it's driver document ! It wrote:
/etc/rc.local
while it must be:
/etc/rc.d/rc.local

Only rc.d missed & this made (& still making) many peoples suffering headache !!

[dswaner]

Wrong was from Canon that did not corrected error in it's driver document ! It wrote:
/etc/rc.local
while it must be:
/etc/rc.d/rc.local

Years ago in Fedora, there used to be a symbolic link from /etc/rc.local to /etc/rc.d/rc.local, so the Canon
documentation used to be correct. That symbolic link may still be there on some Linux's, but
not Fedora.

[User808]

Years ago in Fedora, there used to be a symbolic link from /etc/rc.local to /etc/rc.d/rc.local, so the Canon
documentation used to be correct. That symbolic link may still be there on some Linux's, but
not Fedora.

O.K but I think that it is a shortage from Canon that it do not give time for adding few lines in their documents to be more specific with following distros.:

- Debian
- Ubuntu
- openSUSE
- Fedora

These are most commonly used distros for non servers Linux users.

[HaydnH]

I'm not sure I'd blame Canon here. The traditional (i.e: unix type) way runlevels and rc scripts worked was that you'd have your /etc/rc.N scripts, each of which would go in to the /etc/rc.N.d folders and run each script there in an alphanumeric order. If a company writes a set of instructions based on that which are correct at the time of publishing, I don't think it's their responsibility to monitor changes in all the Linux distributions and Kernel code etc etc to keep their documentation up to date. Perhaps the people making the decisions about removing/moving file locations etc should be more proactive about making their changes known or keeping things backward compatible via symlinks to the moved files?