Hi,
I’ve got CUPS working so I can use my RPiB as a print server.
All working fine until I restart the Pi. I am then unable to access 192.168.1.4:631/admin - CUPS does not seem to be starting when the Pi boots. As soon as I start CUPS manually I can access the admin page.
Any help would be appreciated. Thank you.
Hmmm. Seems to be working now…CUPS restarting after a reboot.
No. Stopped restarting on its own again.
How do I go about getting the service to start automatically?
I tried creating a file and following this guide but it doesn’t work by starting the service:
Had a quick browse at that thread but it talks about upstart and also uses /etc/if-up.d/ scripts - we have neither of those in OSMC.
We use systemd not upstart for the init system, and if-up.d scripts are not currently supported. (But may be added in the future - it’s something we’re looking into)
The best way to start services under systemd is to use a native systemd service unit, but most legacy /etc/init.d/ scripts are supported as well through systemd’s backward compatibility layer. Debian packages seem to use a mixture of the two approaches at the moment as many packages still don’t have systemd scripts even though systemd is standard in Debian Jessie.
Do you know what the service name is ? Assuming it is cups, what does this say:
sudo systemctl status cups
Full debug logs would be helpful.
Thanks so much DBMandrake.
I suspected it had something to do with the newer filesystem. As a non Linux person I’m fumbling through this as best I can with what I can find online via various forums. I’m surprised I got it going in the first place and as far as this.
The service name is definitely “cups”.
If I SSH in and run
sudo service cups restart
It starts the cups service again.
I just stuffed something up and had to do a fresh install from a backup. I’ll install CUPS again and run:
sudo systemctl status cups
I’ll report back.
the service command is deprecated on a systemd system. You would want to use systemctl:
sudo systemctl restart cups
(restarts the service)
sudo systemctl enable cups
(sets it to start on boot)
Familiarise yourself with the start, stop, restart, enable, disable and status options of systemctl on the following page - they are the ones you’d most frequently use when configuring and testing services:
Ok, I’ll have a read.
Debian Jessie seems so much more user friendly than the previous systems…and logical to me. I’m actually enjoying the tinkering now.
Do you think CUPS may or could be added in the OSMC store?
Tried systemctl stop - works
osmc@KodiBed:~$ sudo systemctl stop cups
Warning: Stopping cups.service, but it can still be activated by:
cups.path
cups.socket
Tried systemctl restart - works
osmc@KodiBed:~$ sudo systemctl restart cups
Tried stsyemctl status - works
osmc@KodiBed:~$ sudo systemctl status cups
* cups.service - CUPS Printing Service
Loaded: loaded (/lib/systemd/system/cups.service; enabled)
Active: active (running) since Tue 2015-06-16 20:27:20 AEST; 49s ago
Docs: man:cupsd(8)
man:cupsd.conf(5)
Main PID: 2173 (cupsd)
CGroup: /system.slice/cups.service
`-2173 /usr/sbin/cupsd -f
Given the above
sudo systemctl enable cups
must work. I’m just going to do some more reading from the document you provided.
EDIT:
Ok in /lib/systemd/system there is cups.service
and in /etc/systemd/system/ I have:
/etc/systemd/system/paths.target.wants/
cups.service is there
/etc/systemd/system/sockets.target.wants/
avahi-daemon.socket and cups.socket is there
So I have no idea why after a few days the cups service stops restarting on its own after a reboot.
Looks like it is a proper systemd service - have a look at that file and you’ll see the way the service is configured to start.
systemd works very differently to previous init systems so for people like me used to older init systems it takes a bit of time to wrap your head around it, but there is a lot to like about it once you get comfortable with it.
A systemd service unit can be written in a couple of minutes when you’re familiar with it - not so for a legacy /etc/init.d/ script that is full of complicated boilerplate code 
Here is what is in the /lib/systemd/system/cups.service file:
[Unit]
Description=CUPS Printing Service
Documentation=man:cupsd(8) man:cupsd.conf(5)
Requires=cups.socket
[Service]
ExecStart=/usr/sbin/cupsd -f
PrivateTmp=true
[Install]
Also=cups.socket cups.path
WantedBy=printer.targetI’ve now run:
sudo systemctl enable cups.service
and the output I got was:
osmc@KodiBed:~$ sudo systemctl enable cups.service
Synchronizing state for cups.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d cups defaults
Executing /usr/sbin/update-rc.d cups enable
osmc@KodiBed:~$
Will monitor and see what happens over the next few days.
Rebooted after all that and service not started.
Need to manually:
sudo systemctl restart cups
to get it going again…bugger!
After you reboot, what does systemctl status cups say ?
Also this article seems to suggest that cups only starts on demand when it’s needed ?
Ok, that is interesting that it runs on demand.
systemctl status cups, from memory was saying disabled. That doesn’t mean that it won’t start on demand though…I guess.
I was basing my decision that it wasn’t working on accessing the admin page for CUPS on 192.168.1.4:631. When the service isn’t running it is not possible to access the admin page. When I restarted CUPS the admin page was accessible…obviously.
I’ll see what happens when I do some testing tonight or tomorrow.
Thanks for the help.
Post boot running systemctl status cups:
osmc@KodiBed:~$ sudo systemctl status cups
* cups.service - CUPS Printing Service
Loaded: loaded (/lib/systemd/system/cups.service; enabled)
Active: inactive (dead)
Docs: man:cupsd(8)
man:cupsd.conf(5)
Doesn’t seem to be running “on demand”. The printer is not available until I restart cups.
Something has changed in the recent OSMC updates as CUPS seems to be restarting now @DBMandrake
I have done two manual updates with reboot requests over the last two days and the service has restarted.
Interesting, I wonder if it was this change that “fixed” it:
We discovered a problem with the service dependencies for connman (our network manager) that was causing problems with the ordering of dbus and connman services during startup and shutdown.
The symptom I first noticed is that during shutdown/reboot services that state they need network were not being shut down before connman - thus they would lose their network connection before shutting down. (Normally all network requiring services should shut down before the network is taken down so they can finish up what they are doing)
The changes to fix shutdown ordering will also have changed startup ordering (as they are just mirror images) so it could well have affected your cups problem. (Most likely cups was trying to start before connman before but will now be starting after it)
Looks like it - fantastic!
I was getting something like a kernel panic on startup. The startup OSMC screen had a whole heap of writing scrolling down the screen before startup. This has now stopped.
Thanks for your insight into this “issue”. I tried everything I could with my limited knowledge and dealing with outdated info in other forums.
I saw this thread yesterday too: If-up.d/ scripts not working for all interfaces
I’m still getting white writing scrolling at startup over the OSMC screen @DBMandrake.
It doesn’t have any error messages and I think it’s just related to some services starting up as a result of the CUPS service.
Another reason for boot messages to appear is if there are any unusual delays for services starting up during boot - what counts as “unusual” varies depending on whether other services are being held up by the delayed service or not - if they are, typically it will show a message saying that it is waiting for a service to start after about 10 seconds of the service starting up but still not having finished starting.
With some older legacy init scripts it’s difficult to completely avoid getting such messages saying that it is waiting for a service to start. If you could take a picture of the screen at the instant that text begins to appear over the splash we could probably work out the cause, but there might not be a way to prevent it.
A stock OSMC install doesn’t display any boot time text so it probably is related to cups, or possibly samba if you have that installed.