0

On this server system we have been offloading the ssd system "disk" of high-write loads for reliability / longevity reasons and following one strategy, we went to a new one and everything seemed OK.

However, we discovered that we'd made an error and forgot to remove a sym link that was in /. The purpose of that link was to avoid having to reboot and provide a partition, which we've later done. So, that link pointed to the new disk space for the /var tree. The new strategy just uses a mount point for /var. We rebooted and everything seemed OK. But without removing the symlink, it was odd: Everything seemed to work OK, but if you did realpath in /var it seemed to be on the wrong disk?!

So, we removed the symlink and rebooted and removing the sym link and THAT'S when things went wrong.

The mail files on the intended mount of /var were ALREADY fully up to date, which was surprising. So,over-writing the current /var with the former location - where realpath said it was - seemed like a bad idea. However, Postfix won't start!

It says:

Failed to start postfix.service: Unit var.mount is masked.

I've tried unmasking and have also read and considered the input from this question and this one, too.

So far, we have a "system down" situation!

We still have both disk trees intact, of course!

Asked for Additional Data

I suppose var.mount is a service - never knew that until now but:

  1. systemctl unmask var.mount completes silently. A subsequent attempt to try to either start var.mount or postfix.service repeats the original error message about it being masked.

  2. systemctl status var.mount says:

systemctl status var.mount
● var.mount
     Loaded: masked (Reason: Unit var.mount is masked.)
     Active: active (mounted) since Sat 2023-10-28 12:06:09 PDT; 5h 19min ago
      Where: /var
       What: /dev/sda1
        CPU: 2ms
     CGroup: /system.slice/var.mount

Notice: journal has been rotated since unit was started, output may be incomplete.

Following my own query in a comment below I did a web search and found this article, and so I ran the following:

# systemctl list-unit-files | grep masked
-.mount                                                                   masked-runtime  disabled
boot.mount                                                                masked-runtime  disabled

...all the mounts followed with exactly the same form as boot.mount, just the other mount names with slashes replaced by dashes.

No attempts at unmasking have worked so far, but I'm only using systemctl's unmask command...

...Still digging into it!

Advice is VERY welcome!

Richard T
  • 1,332

1 Answers1

-2

I did a web search for "masked-runtime" and that led me to... (drum-roll) the systemctl man page?! WOAH, who'da thunk the MAN page would have the answer?

That led me to learn about the systemctl option --runtime and when I used it on an unmask command on the mount point I was able to then start postfix the usual way! YAY!

# systemctl unmask var.mount --runtime

From there, I just started postfix the usual way - with another systemctl command!

Now, postfix isn't happy because dovecot isn't happy, but now at least THIS problem is behind me!

Richard T
  • 1,332