Printer sharing service always has to be restarted (Zentyal 3.4)

[jgould]

Yep, definitely logrotate

Confirmed doing the following (must have data in the cups logs for it to work);

logrotate -f /etc/logrotate.conf

Output...

Code: [Select]

2014/07/29 10:03:54| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8'
2014/07/29 10:03:54| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost'
2014/07/29 10:03:54| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2014/07/29 10:03:54| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '::1' from the ACL named 'to_localhost'
2014/07/29 10:03:54| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8'
2014/07/29 10:03:54| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost'
2014/07/29 10:03:54| WARNING: (B) '::1' is a subnetwork of (A) '::1'
2014/07/29 10:03:54| WARNING: because of this '::1' is ignored to keep splay tree searching predictable
2014/07/29 10:03:54| WARNING: You should probably remove '::1' from the ACL named 'to_localhost'
 * Restarting Zentyal module: haproxy                                    [ OK ]
 * Restarting Zentyal module: webadmin                                   [ OK ]
 * Restarting Zentyal module: logs                                       [ OK ]
 * Restarting Zentyal module: events                                     [ OK ]

And after the printer module is down. Interest that it doesn't show the printer module even being restarted, yet if you check /var/logs/cups/ it clearly rotated the logs. So it has to be stopping the module, but not restarting.

If you run it again right after this, because of the ifempty set in the logrotate configuration, it won't rotate the log and therefore doesn't stop/start and everything remains working.

PS: I don't think it is a permissions issue on the log files. I checked and the generated files seem to have the correct permissions. I even forced the creation of the files to be "0640 root adm" and it didn't help.


Here is the /etc/logrotate.d/cups-deamon file contents.

Code: [Select]

/var/log/cups/*log {
        daily
        missingok
        rotate 7
        sharedscripts
        prerotate
                if [ -e /var/run/cups/cupsd.pid ]; then
                        invoke-rc.d --quiet cups stop > /dev/null
                        touch /var/run/cups/cupsd.stopped
                fi
        endscript
        postrotate
                if [ -e /var/run/cups/cupsd.stopped ]; then
                        rm /var/run/cups/cupsd.stopped
                        invoke-rc.d --quiet cups start > /dev/null
                        sleep 10
                fi
        endscript
        compress
        notifempty
        create
}

Something wrong with running the scripts perhaps?

[jgould]

EDIT

Sorry to keep posting, but I'm debugging and want to put all my thoughts somewhere for others.
I'm looking at the prerotate and postrotate scrips in /logrotate/cups-deamon . I'm interested in the following lines.

Code: [Select]

        prerotate
                        ....
                        touch /var/run/cups/cupsd.stopped
                        ...
                fi
        endscript
        postrotate
               ...
                if [ -e /var/run/cups/cupsd.stopped ]; then
                        rm /var/run/cups/cupsd.stopped
               ...

So before rotating the logs it should create a cupsd.stopped file in /var/run/cups/. After the rotation it should check if that file exists (-e) and if it does then remove the file and start cups.

It looks like the prerotate IS working. The cupsd.stopped file IS created. It is also deleted. But process does not start.

[thefreeaccount]

It looks like the prerotate IS working. The cupsd.stopped file IS created. It is also deleted. But process does not start.

Thanks very much for your input and efforts debugging. As you almost certainly already know by now (it sounds like you know a lot more about logrotate than I do), Zentyal does not include a default / fall-through definition for log files; as far as I know, in linux, each daemon has its own rules for logging and has to be restarted in its own way. The only thing the various daemons have in common is that they won't start if they can't write to whatever they consider their log file.

If you do ever figure out what the problem is, I'd really appreciate it if you could post the solution here.

[jgould]

Definitely will post if I determine the problem. Looking at the various permissions and files I haven't come across anything.

The best workaround I can think of right now is;
1) Make a backup of cups-deamon
2) Delete everything in /logrotate/cups-deamon so logrotate shouldn't do anything to the log files now
3) Change the MaxLogSize parameter in /etc/cups/cupsd.conf to MaxLogSize 1048576 (ie. 1M).
4) Optionally, change LogLevel to none

This doesn't do "daily" log rotation. It should allow cups to manage it's own log files and rotate them at a set size. Changing LogLevel to none should just help reduce/remove the logging so it doesn't (accidentally) grown out of control or anything.

EDIT: I'm actually going to fire up a Ubuntu 14.04 VM that has working cups/logrotate and see if the problem exists there. If not then I'll start comparing things and see what I find. Maybe that will help. 

EDIT2: logrotate works as expected in a Ubuntu 14.04 VM. So time to investigate and see what I find...

[jgould]

Files and permissions look the same between fresh Ubuntu 14.04 and Zentyal for the various related files.

The prerotate outputs cups stop/waiting in both installations.
The postrotate outputs cups start/running, process <pid#> in ubuntu, but nothing in Zentyal.

I'm running out of ideas of what to check...

[timroijers]

I edited /etc/logrotate.d/cups-daemon into:

/var/log/cups/*log {
        daily
        missingok
        rotate 7
        sharedscripts
        prerotate
                if [ -e /var/run/cups/cupsd.pid ]; then
                        /etc/init.d/cups stop > /dev/null
# invoke-rc.d --quiet cups stop > /dev/null
                        touch /var/run/cups/cupsd.stopped
                fi
        endscript
        postrotate
                if [ -e /var/run/cups/cupsd.stopped ]; then
                        rm /var/run/cups/cupsd.stopped
                        /etc/init.d/cups start > /dev/null
#invoke-rc.d --quiet cups start > /dev/null
                        sleep 10
                fi
        endscript
        compress
        notifempty
        create
}

---------------------------------

Now everything starts just fine!

[jgould]

I can confirm, it works for me as well. Very strange because "invoke-rc.d --quiet cups stop > /dev/null" is the default in Ubuntu and works without issue. Not so with Zentyal though.

Thanks.

I've got a whole sheet of things I have to do to a Zentyal server after upgrading modules or restarting the server. Not good...

[sramage]

I'm facing the same problem.
I solve it by removing /etc/init/cups.override
this file is set by the package zentyal-printers , it prevent the automatic start of cups daemon
I don't know why zentyal do that

[jbahillo]

This is because Zentyal starts the service using upstart

[jcaudeli]

Yeeeeessssss!!

Works great! Thanks a lot!

I've spent some weeks struggling my mind, trying to understand why the cups daemon was stopped every morning. You are my hero.