Subject: mail_queue_enter: create file maildrop/870989.992: Read-only file system

Hello,
can someone please read the following and give me some feedback??I am
starting to get out of ideas.
I\u2019m on a virtual private server with a freshly installed Debian 13.4.
The server is currently accessible via the FQDN lumi.mylino.net. I
installed a list of packages like libreoffice, monit and certbot, and
created a file |/etc/monit/conf.d/lino.conf| with the following content:
# generated by getlino
set alert root@localhost with reminder on 2 cycles
check program status with path /usr/local/bin/healthcheck.sh
if status != 0 then alert
check device ROOT with path /
if SPACE usage > 95% then alert
check system $HOST
if memory usage > 75% for 5 cycles then alert
This file causes the server to collapse after a few hours of operation.
When I remove the file and reboot the server, my problem disappears. And
when I restore the file and reboot, my problem reappears.
Here is what happens after rebooting when the file exists.
Soon after rebooting, I have the following message in my journal:
apr 28 08:07:30 lumi postfix/postdrop[992]: warning: mail_queue_enter: create file maildrop/870989.992: Read-only file system
This warning reappears every 2 minutes. Which corresponds to the \u201cset daemon 120\u201d in my |/etc/monit/monitrc|. After two minutes, there are already two of these warnings.
And for each warning, |ps aux| shows a new group of four processes:
root 1871 0.0 0.1 18012 2368 ? Ss 22:51 0:00 sudo supervisorctl status
root 1872 0.0 0.3 43956 7044 ? S 22:51 0:00 sendmail -t root 1873 0.0 0.3 43820 7068 ? S 22:51 0:00 /usr/sbin/postdrop -r
postfix 1895 0.0 0.7 53376 14112 ? S 22:52 0:00 tlsmgr -l -t unix -u -c
And these processes accumulate, and after a few hours the server gets
out of memory and starts swapping.
My |/etc/monit/conf.d/lino.conf| file is obviously the trigger, but on
the other hand I\u2019m using the same file on at least one other server with the same Debian version. In general I\u2019m using this file on other servers at least since 2020 <https://gitlab.com/lino-framework/getlino/-/blob/f8b6ac2ffe289dabee7f39a902791824fc7a8ea8/getlino/configure.py>,
and until now it did not cause such a problem.
More observations:
*
I read the docs about tlsmgr <https://www.postfix.org/tlsmgr.8.html>
and yes, everything indicates that some process (probably monit) is
trying to send an email and that postfix has some problem, but my
postfix configuration is a stand-alone internet site with only the
following parameters changed:
# postconf myhostname mydestination myorigin
myhostname = lumi.mylino.net
mydestination = $myhostname,localhost
myorigin = /etc/mailname
And I can manually send an email to root@localhost
<mailto:root%40localhost> by saying:
$ echo foo | mail -rluc@lumi.mylino.net root@localhost
*
|postfix check| doesn\u2019t complain about anything.
Thank you for reading. What else can I try?
Luc


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: mail_queue_enter: create file maildrop/870989.992: Read-only file system

Hi,

On Sun, May 03, 2026 at 02:50:47AM +0300, Luc Saffre wrote:

Soon after rebooting, I have the following message in my journal:

apr 28 08:07:30 lumi postfix/postdrop[992]: warning: mail_queue_enter: create file maildrop/870989.992: Read-only file system

For some reason your filesystem has gone read-only. If I were you I'd be looking further back in the logs to see if there is anything about that,
as I would expect there to be.

The rest of your mail seems to describe the efforts of your system to
deliver email to the root user, which can't happen because the
filesystem is read-only. There's no indication that the reason for it
going read-only is related to postfix or monit (but it could be).

It's not surprising that it does eventually run out of memory if a
frequently running cron job results in several processes that get stuck
each time trying to deliver email. The root cause of the filesystem
going read-only needs to be determined.

Even if the server crashes, the logs from before that should be
available.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: mail_queue_enter: create file maildrop/870989.992: Read-only file system

On Sun, May 03, 2026 at 00:58:35 +0000, Andy Smith wrote:

Hi,

On Sun, May 03, 2026 at 02:50:47AM +0300, Luc Saffre wrote:

Soon after rebooting, I have the following message in my journal:

apr 28 08:07:30 lumi postfix/postdrop[992]: warning: mail_queue_enter: create file maildrop/870989.992: Read-only file system

For some reason your filesystem has gone read-only. If I were you I'd be looking further back in the logs to see if there is anything about that,
as I would expect there to be.

Could be. And a read-only file system is extremely easy to check,
so that should be checked first.

It could also be a restriction added by a systemd unit. Tracking down
all of the restrictions across potentially multiple systemd units will
be more challenging, if it turns out the file system is not read-only.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: mail_queue_enter: create file maildrop/870989.992: Read-only file system

On Sat 02 May 2026 at 22:11:15 (-0400), Greg Wooledge wrote:

On Sun, May 03, 2026 at 00:58:35 +0000, Andy Smith wrote:

On Sun, May 03, 2026 at 02:50:47AM +0300, Luc Saffre wrote:

Soon after rebooting, I have the following message in my journal:

apr 28 08:07:30 lumi postfix/postdrop[992]: warning: mail_queue_enter: create file maildrop/870989.992: Read-only file system

For some reason your filesystem has gone read-only. If I were you I'd be looking further back in the logs to see if there is anything about that,
as I would expect there to be.

Could be. And a read-only file system is extremely easy to check,
so that should be checked first.

It could also be a restriction added by a systemd unit. Tracking down
all of the restrictions across potentially multiple systemd units will
be more challenging, if it turns out the file system is not read-only.

Shouldn't systemd give you "Permission denied"?

Cheers,
David.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: mail_queue_enter: create file maildrop/870989.992: Read-only file system

On Sat, May 02, 2026 at 23:24:44 -0500, David Wright wrote:

On Sat 02 May 2026 at 22:11:15 (-0400), Greg Wooledge wrote:

On Sun, May 03, 2026 at 00:58:35 +0000, Andy Smith wrote:

On Sun, May 03, 2026 at 02:50:47AM +0300, Luc Saffre wrote:

Soon after rebooting, I have the following message in my journal:

apr 28 08:07:30 lumi postfix/postdrop[992]: warning: mail_queue_enter: create file maildrop/870989.992: Read-only file system

For some reason your filesystem has gone read-only. If I were you I'd be looking further back in the logs to see if there is anything about that, as I would expect there to be.

Could be. And a read-only file system is extremely easy to check,
so that should be checked first.

It could also be a restriction added by a systemd unit. Tracking down
all of the restrictions across potentially multiple systemd units will
be more challenging, if it turns out the file system is not read-only.

Shouldn't systemd give you "Permission denied"?

Depends on which restrictions are being used. You can see either one.

See <https://lists.debian.org/debian-user/2026/03/msg00127.html>
and other messages in that thread for a previous instance of this.
Resolution: <https://lists.debian.org/debian-user/2026/03/msg00210.html>

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: mail_queue_enter: create file maildrop/870989.992: Read-only file system

Hi,

On Sat, May 02, 2026 at 10:11:15PM -0400, Greg Wooledge wrote:

On Sun, May 03, 2026 at 00:58:35 +0000, Andy Smith wrote:

For some reason your filesystem has gone read-only. If I were you I'd be looking further back in the logs to see if there is anything about that,
as I would expect there to be.

Could be. And a read-only file system is extremely easy to check,
so that should be checked first.

It could also be a restriction added by a systemd unit. Tracking down
all of the restrictions across potentially multiple systemd units will
be more challenging, if it turns out the file system is not read-only.

I think you are probably right and OP won't find any earlier logging
about a filesystem being globally read-only because it isn't.

Having searched around I've found a few hits for this error message and
many of them involve the thing doing the mail delivery having restricted permissions via the systemd unit.

For example this one with software called netdata involves netdata being started without ability to write /var/spool/postfix/maildrop and getting
the exact same error when trying to send notification emails:

https://www.spamcop.net/sc?id=z6963466407z15976b2b8b2abb7f62add98676d85c9bz

So perhaps OP does need to look at the monit.service file to check it
isn't having its view of the filesystem restricted too severely.

Looking at:

https://sources.debian.org/src/monit/1:5.35.2-3/system/startup/monit.service.in?hl=16#L16

I'm guessing

ProtectSystem=strict

might be the culprit. Although I confess I don't really understand why a process launched by monit would be directly trying to write to the
postfix directory as I would have thought it talks to postfix and then something from postfix delivers the mail. But since the same thing
appears to have happened with netdata and other software then I think
it's got a good chance.

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)