[...]
> To do this, we found "JobPreserveHistory <seconds>" as root option in
> the documentation for /etc/cups/cupsd.conf, which would do the job
> perfectly.
PreserveJobHistory?
Yes, you're right. I shouldn't send out mail after a long shift.. Upps.
[...]
> within the last 86400 seconds, the /var/log/cups/error.log contain the
> Error message
> "E:[Timpestamp] cups sheduler stops through a program error"
I cannot reproduce this. Do you still experience it?
We still have this behaviour, we tested it either with "1d" for one day and also with
the equivalent "86400" in seconds.
We tried it via the webinterface, as also by manually modifying /etc/cups/cupsd.conf
and restarting cups with "systemctl restart cups".
In both cases, the job history is empty and the error_log contain this error message.
[...]
>From my tests it seems that PreserveJobHistory cannot handle being
given any seconds value, small or large. What do you get with 30 for
PreserveJobHistory?
I will test it, but if it work that way, either the implementation is buggy or the documentation
for this option isn't correct... I prefer the first one to be fixed. ;-)
Edit: I tested "PreserveJobHistory" with several values: 60, 1024, 86400 by manually editing /etc/cups/cupsd.conf
and after each modification, I did a service restart.
Expecting: JobHistory will listing test print jobs within the specified time frame, not listing them after the given time frame exeeds
What happened: In each case, all job files (*.c, *.d) under /var/spool/cups are deleted, even the creation date of the file was not exeeding the tested value.
Instead of originally reported, the error_log contained no error after a service restart.
I did not test also by changing the values via the webinterface.
PreserveJobHistory seems not handling numeric values as otherwise described as possible value in the cupsd.conf(5)-documentation.
Instead, it handle numeric values like the option value "No" and disable the job history completely.
Kind regards.
Emin Kaya