I got a CUPS remoter printer setup with encryption.
I'm using Lets Encrypt to generate a cert, then I symlinked them to the /etc/cups/ssl/... location since using cat even as sudo said permission denied. I'm forwarding the domain with NGINX.

Anyway it works, it has https and the prints make it... however the cups service seems to keep dying.

Where the printers will no longer appear in the browser options to print.

I don't know why, I'm looking at cups error log there does not seem to be anything obvious.

I initially did have problems with host name but I added a ServerAlias.

I'm not sure what it could be. The server isn't beefy but it's the only thing it's running, 1 CPU core, 1GB of RAM and at this time there are only 2 printers/barely used/mostly idle.

After a while the cups service says it's inactive and I have to restart cups.

Any ideas?

As an aside, I've been using a CUPS printer (unencrypted) with the same EC2 spec and it has been running without problems for a couple months now so I think it's something with my encryption setup...

Ahh crap, I just checked, the other one has 2GB of RAM maybe it is running out of memory

It also takes longer to restart cups on this smaller/encrypted CUPS server. The resource usage is not that high though, it's just under 200M/974M

The plot thiccens

Attached Thumbnails

 

Have you looked in the CUPS error log? It might contain information that could help shed some light on this.

It's normally located in /var/log/cups/

I have it just stopped after I tweaked some things. It still works and dies, but no logs come out.
It's not a rotation thing either and the other printer logs are empty.
Nothing in dmesg.

The printer logs do the standard dump, success "all memory has been freed" after the job is done.

I've omitted domain name but this is it, full log since I created/setup this server earlier today.

Changed I applied, I mentioned I added the ServerAlias * line.

The line "invalid host: field" it's a domain name, format is: subdomain.domain.tld

NGINX forwarding config is

location /printers {
proxy_pass http://localhost:631;
proxy_set_header Host "127.0.0.1";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
}


I listen to 443 on the NGINX server and proxy as above

Anyway thanks for taking a look

Let me clear out this log, maybe it's exactly the same although the time is advancing

I probably did clobber together some monstrosity that somewhat works, I'm not a network/sysadmin guy.

Yeah so it died again, but no logs... I wonder when I edited the log, did I change its permission or something so that cups isn't writing to it... I wouldn't think so it was root:admin owned. I checked against another stock running instance, same perms/ownership hmm.

Attached Thumbnails

 

Hi

I do not run any servers but that second image definately shows probs with hostname and encryption. Maybe (for a diff address)
https://ubuntu.com/server/docs/service-cups

One image shows cups is dead/inactive. That might be just a timing thing.

Have you considered created a daily cron job to 'restart' cups using whatever systemd commands are.
then if it dies within the day....look at a cron job on a hourly basis if needed

maybe try command for systemd distros....sudo systemctl restart cups.service

edit
https://askubuntu.com/questions/2368...-up-a-cron-job

Yeah I saw somebody else do that, the cron job... I'm just trying to figure out why this one is so bad... it dies in minutes.
The other one (non-encrypted) stays alive for like 22hrs straight.

Those logs were when I was first monkeying around with the settings to get the proxying to work.

The thing works, when CUPS is actually running and right now after I emptied the logs nothing's being written to them.

Despite the service dying again.

Thanks for the thoughts, I'll read up on the service-cups.

I thought I read somewhere that CUPS has its own webserver, so maybe I don't need to do the NGINX forwarding?

I'm using Listen localhost:631 in my cupsd.conf file

Location / is using
allow 127.0.0.1;
deny all;

syslog has more info

Ahh yeah the clock is way off on this server, I just looked at some logs produced now from a successful print and it says Sep 25 3:13... that's what I mean by the errors from above with the host name were from like from 12hrs ago/more.

I attached the nginx conf and cupsd.conf

cupsd.conf is mostly stock, only place I modified are near the port, adding the server alias and then towards the bottom forcing encryption/key location.

I know there's a lot of crap in here but this particular server those other ports are not doing anything currently. This is a service nginx config from the other unencrypted one that works fine.

Trying a bigger server did not help, now I have a red dot that's interesting.

Attached Thumbnails

     

Attached Files

cupsd.conf.txt (6.2 KB, 8 views)

So I noticed a difference between my encrypted/proxied CUPS instances and the old one... the old one the service is triggered by cups.socket and my current ones are triggered by cups.path...
I also had the webinterface on for my old one... although no one is viewing it so I wouldn't think the service is kept up by that.
I made a change to the cups systemd files...

/lib/systemd/system/cups.service

I set

Restart=always
RestartSec=3

Not sure the implications of that, I'll monitor the resources used.
I just need these printers to stay up/on all the time. 3 second down time I think is within "human conscious lag" haha, acceptable time to wait for something to reconnect.

Well they all say socket now... will keep an eye on it

Yeah for some reason it keeps stopping and starting over and over again the cups scheduler

As long as it doesn't stop a print queue guess I'm fine

I'm gonna let it sit for a couple hours and see, will probably say "active since 2 mins ago or something"

ahh I do not run a remote printer but my earlier link shows a LAN listen
https://ubuntu.com/server/docs/service-cups
Your config shows only list to local. I assume because your printer is still working.....that is good enough

but as your "LogLevel warn" setting means you do not get a fuller range of debug info when you view your error log.
For a litle while maybe change to
LogLevel debug

and restart your cups service.....depending on the distro....saving that change might initiate a cups restart in any case.

I am not hitting port 631 externally. I'm forwarding the 443 port to 631 by nginx. On the EC2 config port 631 is shutoff.
Not sure if that matters, I could be not understanding the ports too.

I will look into LogLevel debug, I was able to "fix it" but it's weird that it dies so quickly.

Yeah the Debug was a good tip, I see at least a warning about putting the cert files in another file as it will be an error in the future.

The other non-encrypted server that's doing fine, it has some services running on different ports.

I saw you can trigger cups to stay on by some port or some action, one example I saw was using port 631 if you use the web interface (I don't intend to).

I don't know if that's related somehow... I will found out later when I turn the same services on in the same encrypted cups server.

Looking at the start/restart logs overnight, it seems to do it at intervals of 1.5mins