archivesspace.out now is a binary file?

[Mang Sun]

We are on Aspace 3.5. Today, I suddenly noticed the Aspace's logfile is no longer a plain text file any more.

#less archivesspace.out
"archivesspace.out" may be a binary file.  See it anyway?

But #tail -f archivesspace.out can still get regular output. I haven't touched Aspace's backend for a long time. Anything abnormal or changed? We upgraded our Apace 2.7.x to 3.5 back in early 2024.

Thank you.

Mang Sun

Rice U.

[Blake Carver]

I've seen that happen, sometimes the file just gets corrupted. Just restarting ArchivesSpace should start a new file.

---

From: archivesspac...@lyrasislists.org <archivesspac...@lyrasislists.org> on behalf of Mang Sun <ms...@rice.edu>
Sent: Thursday, June 18, 2026 3:27 PM
To: Archivesspace_Users_Group <archivesspac...@lyrasislists.org>
Subject: [ArchivesSpace Users Group] archivesspace.out now is a binary file?

 

You don't often get email from ms...@rice.edu. Learn why this is important

--
You received this message because you are subscribed to the Google Groups "Archivesspace_Users_Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Archivesspace_User...@lyrasislists.org.
To view this discussion visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/5ecb74d4-6fad-4213-bd60-92a0bd3c6c13n%40lyrasislists.org.

[Mang Sun]

Blake,  I also noticed (but subject to further observation and test )the log file is not reset but keeps growing  when our logrotate script restarts the Aspace and archives the current log file. When the log file is small, command less can handle it. We are on RHEL 9. Thank you.

Mang

[Blake Carver]

It may just be so large you'll need to delete it manually.

---

From: Mang Sun <ms...@rice.edu>
Sent: Monday, June 22, 2026 12:19 PM
To: Archivesspace_Users_Group <archivesspac...@lyrasislists.org>
Cc: Blake Carver <blake....@lyrasis.org>
Subject: Re: [ArchivesSpace Users Group] archivesspace.out now is a binary file?

 

[Otken, Stan]

Hi Mang,

 

From my experience, the lorgotate copytruncate option does not work reliably with ArchivesSpace 3.~ under RHEL9. The JVM keeps the logfile open and continues writing through the existing file descriptor after Logrotate truncates the file. Because the application does not reopen its log file, rotation can result in missing, malformed, or otherwise unusable log data, and the file continues to grow in size. ArchivesSpace also does not appear to safely support SIGHUP-based log reopening; my testing showed that sending SIGHUP caused the application to terminate. As a result, the most reliable approach for us was to stop the service before rotation and restart it afterward, as exhibited in the prerotate and postrotate options in my example below.

 

/opt/archivesspace/logs/archivesspace.out {

    monthly

    maxsize 1024M

    rotate 8

    dateext

    compress

    notifempty

    missingok

    prerotate

        /opt/archivesspace/archivesspace.sh stop > /dev/null 2>&1

    endscript

    postrotate

        /opt/archivesspace/archivesspace.sh start > /dev/null 2>&1

    endscript

}

References:

https://linux.die.net/man/8/logrotate

https://unix.stackexchange.com/questions/117852/logrotate-wont-truncate-original-file

https://serverfault.com/questions/221337/logrotate-successful-original-file-goes-back-to-original-size

 

Thanks,

Stan Otken

Client Technologies Analyst

Library Technology Services

Mary and Jeff Bell Library

Texas A&M University-Corpus Christi

To view this discussion visit https://groups.google.com/a/lyrasislists.org/d/msgid/Archivesspace_Users_Group/DM6PR22MB2309E198CDDA268D547CA8F29FEF2%40DM6PR22MB2309.namprd22.prod.outlook.com.

[mang...@rice.edu]

Stan,

We do stop/start in the postrotate section. Now I will try your suggestion - split stop/start into prerotate and postrotate. 

Thank you. 

Mang

--

Systems Librarian

Fondren Library

Rice University