0

I need to start the icecast2 service on startup.

To to make it run on boot, I added to crontab (root) the following line:

@reboot service icecast2 start >/home/pi/logs/icecast2.log 2>&1

after restart, the service doesn't run and I get this error:

/bin/sh: 1: service: not found

So I followed this answer on a similar thread, and added the full path as suggested:

@reboot service /usr/bin/icecast2 start >/home/pi/logs/icecast2.log 2>&1

but now I got this error:

Failed to start usr-bin-icecast2.service.mount: Unit usr-bin-icecast2.service.mount not found.

Notes:

  • When I type sudo service icecast2 start it works.
  • Using Debian Scratch on a Raspberry pi
2

You don't need to use cron to get a service to start a boot.

All you need is this:

systemctl enable icecast2

That will start it on boot every time.

  • Thank you! I have a follow up question, will the same syntax work for darkice? – Dante Sep 24 '18 at 16:00
  • Running darkice from crontab works on reboot btw – Dante Sep 24 '18 at 16:00
  • @Dante Yes, that syntax will work for any service. You can start them with crontab but it's not needed as running that command with systemctl does the same thing much more easily. – Nasir Riley Sep 24 '18 at 16:28
  • Great, tnx again! – Dante Sep 24 '18 at 16:29
0

The service program expect parameter 1 to be an executable within /etc/init.d/ directory. In the crontab file, you specified the path to the icecast2 executable.

You should read up on init systems for Debian/Unix. AFAIK, Debian uses the now de-facto standard systemd init system, which is responsible to start services at boot (and much more), while service is now a wrapper script for systemd's systemctl, which controls the services (now called Units) like so:

systemctl start icecast2

But service will remain backwards-compatible to the old init system (called sysvinit), so you can still use service instead of systemctl.

Starting your services/daemons via cron is discouraged, since the de-facto standard is to define systemd units which offer a better structure and more functionality, or using old-school runlevel scripts in /etc/rc.d that are called automatically once the kernel reaches a certain runlevel ("boot state").

Do yourself a favor and search for the terms mentioned above on the web, lots of fun are to be had.

  • That first sentence is not actually true. – JdeBP Sep 24 '18 at 11:52
  • Can you elaborate on that @JdeBP? From man service: The SCRIPT parameter specifies a System V init script, located in /etc/init.d/SCRIPT, or the name of a systemd unit. The existence of a systemd unit of the same name as a script in /etc/init.d will cause the unit to take precedence over the init.d script. The supported values of COMMAND depend on the invoked script. service passes COMMAND and OPTIONS to the init script unmodified. For systemd units, start, stop, status, and reload are passed through to their systemctl/initctl equiv- alents. – NoMad Sep 25 '18 at 7:49
  • I don't need to. Read what you just quoted. Indeed, one can make a stronger statement than even the manual does. Setting aside --status-all which simply fails to work correctly because it looks at /etc/init.d, on systemd Debian operating systems the service command from Debian's init-system-helpers never expects a filename within /etc/init.d. – JdeBP Sep 25 '18 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.