I read the messages from the system in the terminal. It comes daily a message or two from the cron jobs. Here is the problem: I miss the messages from the last two days. I can maybe have deleted them without knowing. The last message is from thursday, but when I double click on the mbox file in my home directory, it shows the last message, and the message is from today, so the two messages are somewhere.
So my question is it a command to undelete messages in the terminal? Or is it possible to open the mbox file in some program so I can see the missing messages?
It would be very nice to se those messages because something changed during the cron jobs, and I want to find out why.
Well, it depends of course on who’s crontab it is. When this is about cron jobs run by a user, you are correct that the user must be able to see them by using the mail/mailx command.
As you have seen the man page for mailx is quite huge and I assume not many people are using mail/mailx very often today (apart from what you are trying to do, inspecting local mails send by processes on the system).
I am with you that when the mail is still in your mbox file, mail should present it.
You might check your system log (journalctl) instead of your mailbox to verify reported events executed successfully(or not).
No idea what might have happened to your missing mailbox messages, maybe “mailbox full” or something similar like free disk space?
Also, your system messages are delivered only to your User mailbox and not root because IIRC that’s the default configuration in an openSUSE install (but can be changed).
dagr@opensuse:~> grep inet /etc/postfix/main.cf
# The inet_interfaces parameter specifies the network interface
#inet_interfaces = all
#inet_interfaces = $myhostname
#inet_interfaces = $myhostname, localhost
# the address list specified with the inet_interfaces parameter.
# receives mail on (see the inet_interfaces parameter).
# to $mydestination, $inet_interfaces or $proxy_interfaces.
# ${proxy,inet}_interfaces, while $local_recipient_maps is non-empty
# - destinations that match $inet_interfaces or $proxy_interfaces,
# unknown@$inet_interfaces] or unknown@$proxy_interfaces] is returned
inet_interfaces = localhost
inet_protocols = all
Here is the content of /etc/sysctl.d/99-sysctl.conf:
####
#
# /etc/sysctl.conf is meant for local sysctl settings
#
# sysctl reads settings from the following locations:
# /boot/sysctl.conf-<kernelversion>
# /lib/sysctl.d/*.conf
# /usr/lib/sysctl.d/*.conf
# /usr/local/lib/sysctl.d/*.conf
# /etc/sysctl.d/*.conf
# /run/sysctl.d/*.conf
# /etc/sysctl.conf
#
# To disable or override a distribution provided file just place a
# file with the same name in /etc/sysctl.d/
#
# See sysctl.conf(5), sysctl.d(5) and sysctl(8) for more information
#
####
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0
First I thought IPv6 was some special server settings I didn’t need. Second I had some problems with Wicked service, so I changed to Network manager service. The message I got was:
More than one interface asks to control the hostname via DHCP. If you keep the current settings, the behavior is non deterministic.
Involved configuration files:
ifcfg-en2s0 dhcp
I thought the problem was solved when I switched to Network manager service. From the information you have got from me, can you see witch interfaces I should change and to what? The IPv6 i can easily turn on.
I may be missing something (and willing to admit fault when mistaken),
But, I wonder if your current networking configuration was the cause of the missing messages, it probably does not explain how messages are now being delivered successfully again with no change to the networking configuration.
I can’t find any documentation that clearly describes how messages are being delivered to the target mailbox, so I can’t even be certain that a system’s internal messages use network sockets as the delivery method. If that can be determined, it might go a long ways towards identifying and eliminating causes.
That is why I suggested possibly looking for another cause for the missing messages, for instance whether the cron jobs didn’t run on those days.
Yes, we don’t have a complete picture here I suspect
I can’t find any documentation that clearly describes how messages are being delivered to the target mailbox, so I can’t even be certain that a system’s internal messages use network sockets as the delivery method. If that can be determined, it might go a long ways towards identifying and eliminating causes.
TSU
As the discussion was around cron job notifications, I assume sendmail by default, (and postfix is listening to localhost on port 25 of course). From ‘man cron’…
-m This option allows you to specify a shell command to use for sending Cron mail output instead of using sendmail(8) This
command must accept a fully formatted mail message (with headers) on standard input and send it as a mail message to the
recipients specified in the mail headers. Specifying the string off (i.e., crond -m off) will disable the sending of
mail.
Apologies if I’ve misunderstood what you’re asking here.