Sendmail auth mechanisms missing after upgrade to Fedora 37

[Scott van Looy via users]

Hi,

Having upgraded to the new Fedora 37, I cannot now send mail via sendmail 
remotely using auth.


Looking at /var/log/maillog, when I try and connect to send an email I 
get:


"AUTH warning: no mechanisms”

Looking at the application log I can see:

250- Hello , pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-DELIVERBY
250 HELP

So it does indeed look like there are no auth mechanisms present

I haven’t changed my config, it was working before the upgrade and the 
only thing I’ve been able to find online that vaguely looks like it might 
be the same issue is this:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263287

sendmail.mc has:

define(`confAUTH_OPTIONS', `A p y’)dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl
define(`confAUTH_MECHANISMS', `LOGIN PLAIN’)dnl

Which all looks correct to me. I’m at a bit of a loss. Does anyone have 
any suggestions as to what might be the issue/what I might be able to do?


Regards,

Scott

--
Scott van Looy___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

MongoDB Community edition

[Scott van Looy via users]

Hi,

Does anyone have any hints for installing MongoDB on Fedora 34? I updated from 
F33 and whilst it’s still working/running, I can’t update it.

Am I missing a compat lib or something?

I’m using the repo at 
https://repo.mongodb.org/yum/redhat/8Server/mongodb-org/4.4/x86_64/ 
 as 
recommended in their docs

When I try and do an update I get:

[root@server ~]# yum upgrade
Last metadata expiration check: 0:30:19 ago on Fri 23 Jul 2021 14:03:10 BST.
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package 
mongodb-org-database-tools-extra-4.4.4-1.el8.x86_64
  - nothing provides /usr/libexec/platform-python needed by 
mongodb-org-database-tools-extra-4.4.7-1.el8.x86_64
 Problem 2: package mongodb-org-tools-4.4.7-1.el8.x86_64 requires 
mongodb-org-database-tools-extra = 4.4.7, but none of the providers can be 
installed
  - cannot install the best update candidate for package 
mongodb-org-tools-4.4.4-1.el8.x86_64
  - nothing provides /usr/libexec/platform-python needed by 
mongodb-org-database-tools-extra-4.4.7-1.el8.x86_64
 Problem 3: package mongodb-org-4.4.7-1.el8.x86_64 requires mongodb-org-tools = 
4.4.7, but none of the providers can be installed
  - package mongodb-org-tools-4.4.7-1.el8.x86_64 requires 
mongodb-org-database-tools-extra = 4.4.7, but none of the providers can be 
installed
  - cannot install the best update candidate for package 
mongodb-org-4.4.4-1.el8.x86_64
  - nothing provides /usr/libexec/platform-python needed by 
mongodb-org-database-tools-extra-4.4.7-1.el8.x86_64
 Problem 4: problem with installed package mongodb-org-4.4.4-1.el8.x86_64
  - package mongodb-org-4.4.4-1.el8.x86_64 requires mongodb-org-mongos = 4.4.4, 
but none of the providers can be installed
  - package mongodb-org-4.4.5-1.el8.x86_64 requires mongodb-org-tools = 4.4.5, 
but none of the providers can be installed
  - package mongodb-org-4.4.6-1.el8.x86_64 requires mongodb-org-tools = 4.4.6, 
but none of the providers can be installed
  - package mongodb-org-4.4.7-1.el8.x86_64 requires mongodb-org-tools = 4.4.7, 
but none of the providers can be installed
  - cannot install both mongodb-org-mongos-4.4.7-1.el8.x86_64 and 
mongodb-org-mongos-4.4.4-1.el8.x86_64
  - package mongodb-org-tools-4.4.5-1.el8.x86_64 requires 
mongodb-org-database-tools-extra = 4.4.5, but none of the providers can be 
installed
  - package mongodb-org-tools-4.4.6-1.el8.x86_64 requires 
mongodb-org-database-tools-extra = 4.4.6, but none of the providers can be 
installed
  - package mongodb-org-tools-4.4.7-1.el8.x86_64 requires 
mongodb-org-database-tools-extra = 4.4.7, but none of the providers can be 
installed
  - cannot install the best update candidate for package 
mongodb-org-mongos-4.4.4-1.el8.x86_64
  - nothing provides /usr/libexec/platform-python needed by 
mongodb-org-database-tools-extra-4.4.5-1.el8.x86_64
  - nothing provides /usr/libexec/platform-python needed by 
mongodb-org-database-tools-extra-4.4.6-1.el8.x86_64
  - nothing provides /usr/libexec/platform-python needed by 
mongodb-org-database-tools-extra-4.4.7-1.el8.x86_64

Regards,

Scott


signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Network problem

[Scott van Looy via users]

> On 5. Nov 2020, at 03:17, Jonathan Billings  wrote:
> 
> On Nov 4, 2020, at 18:39, Roger Heflin  wrote:
>> 
>> Typically if you want put 3 ip addresses in the same subnet on a
>> network usually you use a single network adaptor and add extra VIPs on
>> it.
>> 
>> see: 
>> https://www.jamescoyle.net/how-to/307-create-a-virtual-ip-address-in-linux
>> 
>> eth0:1  for the device names it the 1st vip, :1 as the 2nd vip and so
>> on.  They all exist on the same adaptor.
>> 
>> with the same network on all 3 what interface it goes out can be
>> different than the one it came in and this can cause significant
>> issues on the network.
> 
> Unfortunately, this is rather out of date advice and not supported with 
> modern tools.
> 
> You can just put all IPs on one interface using NetworkManager or the ‘ip’ 
> tool.  Even the old network-scripts method uses IPADDR1=, IPADDR2=, and so 
> on, all on one named interface.  ‘Ifconfig’ is no longer installed by default 
> and doesn’t support many features.

Thanks for the help! Fixed it :)

Scott


signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Network problem

[Scott van Looy via users]

Hi,

I’ve managed to do something accidentally to my network config and I’m not sure 
what.

I’m running a server inside of an ESXi host

It’s running using NetworkManager with 3x fixed IP addresses manually 
configured, .215, .216 and .217

There are 3 virtual adaptors attached to the VM in question, I shut it down, 
updated the host and then started it up again.

So on startup, all 3 appear to be working and have IPs assigned according to 
ifconfig, but...

.215 accepts pings, .216 and .217 do not

If I turn off the adaptor assigned .215, .216 suddenly starts accepting ping 
requests.

If I turn .215 back on again, only .216 continues to accept ping requests.

If I turn off .216 then one of either .215 or .217 will start to accept ping 
requests. And so on.

It’s super frustrating. Does anyone have any ideas why this might happen or 
what could be causing it or any suggestions for what I can investigate?

Regards,

Scott


signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Fail2ban-all

[Scott van Looy via users]

I’m running F32

Trying to update today and I get:

Problem: cannot install the best update candidate for package 
fail2ban-all-0.11.1-6.fc32.noarch
  - nothing provides python2-inotify needed by fail2ban-all-0.11.1-9.fc32.noarch

Anyone have any ideas if this is something I’ve done or if there’s a bug for 
this?

Scott


signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: F32 Supervisord

[Scott van Looy via users]

Answering my own question - seems there’s a version in Rawhide that works - the 
change was made upstream for supervisor 4.1 and current Fedora version is 4.0.4

> On 1. May 2020, at 08:16, Scott van Looy via users 
>  wrote:
> 
> Signed PGP part
> Hi,
> 
> I upgraded to F32 and now I get an error when I try and run Supervisord - am 
> I missing a compat library or something?
> 
> supervisorctl status
> Traceback (most recent call last):
>   File "/usr/bin/supervisorctl", line 11, in 
> load_entry_point('supervisor==4.0.4', 'console_scripts', 
> 'supervisorctl')()
>   File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 
> 489, in load_entry_point
> return get_distribution(dist).load_entry_point(group, name)
>   File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 
> 2852, in load_entry_point
> return ep.load()
>   File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 
> 2443, in load
> return self.resolve()
>   File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 
> 2449, in resolve
> module = __import__(self.module_name, fromlist=['__name__'], level=0)
>   File "/usr/lib/python3.8/site-packages/supervisor/supervisorctl.py", line 
> 40, in 
> from supervisor.options import ClientOptions
>   File "/usr/lib/python3.8/site-packages/supervisor/options.py", line 54, in 
> 
> from supervisor import xmlrpc
>   File "/usr/lib/python3.8/site-packages/supervisor/xmlrpc.py", line 24, in 
> 
> from supervisor.http import NOT_DONE_YET
>   File "/usr/lib/python3.8/site-packages/supervisor/http.py", line 24, in 
> 
> from supervisor.medusa import default_handler
>   File 
> "/usr/lib/python3.8/site-packages/supervisor/medusa/default_handler.py", line 
> 20, in 
> from supervisor.medusa.util import html_repr
>   File "/usr/lib/python3.8/site-packages/supervisor/medusa/util.py", line 1, 
> in 
> from cgi import escape
> ImportError: cannot import name 'escape' from 'cgi' 
> (/usr/lib64/python3.8/cgi.py)
> 
> 
> Regards,
> 
> Scott
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

F32 Supervisord

[Scott van Looy via users]

Hi,

I upgraded to F32 and now I get an error when I try and run Supervisord - am I 
missing a compat library or something?

supervisorctl status
Traceback (most recent call last):
  File "/usr/bin/supervisorctl", line 11, in 
load_entry_point('supervisor==4.0.4', 'console_scripts', 'supervisorctl')()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 489, 
in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2852, 
in load_entry_point
return ep.load()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2443, 
in load
return self.resolve()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2449, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3.8/site-packages/supervisor/supervisorctl.py", line 40, 
in 
from supervisor.options import ClientOptions
  File "/usr/lib/python3.8/site-packages/supervisor/options.py", line 54, in 

from supervisor import xmlrpc
  File "/usr/lib/python3.8/site-packages/supervisor/xmlrpc.py", line 24, in 

from supervisor.http import NOT_DONE_YET
  File "/usr/lib/python3.8/site-packages/supervisor/http.py", line 24, in 

from supervisor.medusa import default_handler
  File "/usr/lib/python3.8/site-packages/supervisor/medusa/default_handler.py", 
line 20, in 
from supervisor.medusa.util import html_repr
  File "/usr/lib/python3.8/site-packages/supervisor/medusa/util.py", line 1, in 

from cgi import escape
ImportError: cannot import name 'escape' from 'cgi' 
(/usr/lib64/python3.8/cgi.py)


Regards,

Scott


signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

http failing on boot

[Scott van Looy via users]

This is probably something super simple, but…

My httpd is failing on boot.

The server has 3x adaptors, all are static IPs and don’t require DHCP or 
anything. Addresses, etc are specified in the config files. All are present 
once boot has ended. All are managed by NetworkManager, yet I get this error in 
the log

Feb 21 07:40:15  systemd[1]: Starting The Apache HTTP Server...
Feb 21 07:40:16  httpd[1012]: [Fri Feb 21 07:40:16.208953 2020] 
[so:warn] [pid 1012:tid 140114180026688] AH01574: module ssl_module is already 
loaded, skipping
Feb 21 07:40:16  httpd[1012]: (99)Cannot assign requested address: 
AH00072: make_sock: could not bind to address :80
Feb 21 07:40:16  httpd[1012]: no listening sockets available, shutting 
down
Feb 21 07:40:16  httpd[1012]: AH00015: Unable to open logs
Feb 21 07:40:16  systemd[1]: httpd.service: Main process exited, 
code=exited, status=1/FAILURE
Feb 21 07:40:16  systemd[1]: httpd.service: Failed with result 
'exit-code'.
Feb 21 07:40:16  systemd[1]: Failed to start The Apache HTTP Server.

It’s like httpd is starting too early.

Looking at the service info I can see it’s supposed to start after 
network.target. Looking at its critical chain using systemd-analyze it seems to 
be doing this correctly. I’m kinda at a loss. Does anyone have any suggestions 
as to what I can try?

Scott


signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: spamprobe

[Scott van Looy via users]

db_verify sp_words

Lots of lines like:
db_verify: BDB1087 Page 5308: Btree level incorrect: got 0, expected 1
db_verify: BDB0501 Page 5309: btree or recno page is of inappropriate type 0
db_verify: BDB0502 Page 5309: totally zeroed page

Then

db_verify: sp_words: BDB0090 DB_VERIFY_BAD: Database verification failed
BDB5105 Verification of sp_words failed.

db_recover seems to run very quick and at the end I end up with an additional 
10mb file called log.01 and I don’t know what to do with it. The 
original db file remains the same

Running with -v gives me

BDB2526 Finding last valid log LSN: file: 1 offset 28

But I’m pretty confused about how this is meant to work!

Scott

On 1. May 2019, at 20:48, Samuel Sieb  wrote:
> 
> On 5/1/19 1:22 AM, Scott van Looy via users wrote:
>>> On 1. May 2019, at 09:22, Samuel Sieb  wrote:
>>> 
>>> On 4/30/19 11:30 PM, Scott van Looy via users wrote:
>>>> What format does spamprobe use for the db and is it repairable somehow?
>>> 
>>> Try running the "file" command on the database file and see what it says.  
>>> What is the filename?
>> sp_words: Berkeley DB (Btree, version 9, native byte-order)
> 
> Make a copy of the directory and you can try the db_* utilities like 
> db_verify and db_recover.
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org



signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: spamprobe

[Scott van Looy via users]

> On 1. May 2019, at 09:22, Samuel Sieb  wrote:
> 
> On 4/30/19 11:30 PM, Scott van Looy via users wrote:
>> What format does spamprobe use for the db and is it repairable somehow?
> 
> Try running the "file" command on the database file and see what it says.  
> What is the filename?

sp_words: Berkeley DB (Btree, version 9, native byte-order)

> 
>> Alternatively - I set this up about 750,000 years ago, I can see spamprobe 
>> hasn’t been updated in years, is there a better solution to set up spam 
>> filtering on fedora? I run my own mail server and I currently use RBLs and 
>> spamassassin
> 
> I use spamassassin, sqlgrey, and RBLs.

Cool thanks.

> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org



signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

spamprobe

[Scott van Looy via users]

Hi,

I recently recovered my home partition from some corruption. Most of everything 
is working OK but my spamprobe database appears not to be

I use spam probe in a procmail recipe, from their examples in the man page:

:0
SCORE=| /bin/spamprobe train
:0 wf
| formail -I "X-SpamProbe: $SCORE"
:0 a:
*^X-SpamProbe: SPAM
spam

And procmail is hanging on “spamprobe,train”, timing out and failing to deliver 
the message.

I moved my existing spamprobe database away and created a new one and it all 
works as expected, but without any of my previous data from the old DB.

So, two questions:

What format does spamprobe use for the db and is it repairable somehow?

Alternatively - I set this up about 750,000 years ago, I can see spamprobe 
hasn’t been updated in years, is there a better solution to set up spam 
filtering on fedora? I run my own mail server and I currently use RBLs and 
spamassassin

Regards,

Scott



signature.asc
Description: Message signed with OpenPGP
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: HTTPD shutting down every night

[Scott van Looy via users]

So httpd survived Tuesday without crashing but crashed again yesterday and 
today.

In /var/log/messages I can see:

Nov 14 03:26:57 novak systemd[1]: Reloading The Apache HTTP Server.
Nov 14 03:26:57 novak systemd[739346]: httpd.service: Failed to set up mount 
namespacing: No such file or directory
Nov 14 03:26:57 novak systemd[739346]: httpd.service: Failed at step NAMESPACE 
spawning /usr/sbin/httpd: No such file or directory
Nov 14 03:26:57 novak systemd[1]: httpd.service: Control process exited, 
code=exited status=226

And then a little later

Nov 14 03:26:58 novak systemd[1]: httpd.service: Killing process 230630 
(nss_pcache) with signal SIGKILL.
Nov 14 03:26:58 novak systemd[1]: httpd.service: Failed with result 'exit-code'.
Nov 14 03:26:58 novak systemd[1]: Reload failed for The Apache HTTP Server.
Nov 14 03:26:58 novak audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=httpd comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Nov 14 03:26:58 novak logrotate[739362]: ALERT exited abnormally with [1]

Googling the NAMESPACE error I find a post about /tmp or /var/tmp being 
symbolic links. Neither are.

Yesterday I reinstalled httpd from scratch, last night it crashed again in the 
same way.

Does anyone know what user logrotate runs as? I’ve tried /bin/systemctl reload 
httpd.service as root and it reloads as expected and am wondering if there’s 
something else weird going on here?

Regards,

Scott

> On 12. Nov 2018, at 16:32, Scott van Looy via users 
>  wrote:
> 
> Thanks for this.
> 
> Certwatch is uninstalled now, it just tells me if any of my certs have 
> expired and as I don’t have any on that box any more it’s kinda pointless :)
> 
> I’ve removed the stuff to hide the output from the apache restart in 
> logrotate so I’m going to let it run tonight and see if anything exciting 
> gets logged
> 
> Regards,
> 
> Scott
> 
>> On 12. Nov 2018, at 16:08, Andy Blanchard  wrote:
>> 
>> Of that bunch, autodld (downloading RPMs) and rkhunter (scanning the
>> filesystem, taking checksums, and looking for changes) are both
>> passive, certwatch probably shouldn't be updating certificates every
>> 24 hours (but could do, so worth checking!), and logwatch just parses
>> the existing logfiles - it shouldn't touch the daemons.  That leaves
>> logrotate as the prime suspect, IMHO, as that definitely HUPs/restarts
>> daemons after it rotates logfiles.  However, it also tracks when it
>> was last run and won't cycle a logfile and HUP a daemon if it doesn't
>> need to - since it's already cycled the logs at 03:54, it won't do so
>> again when you're trying to run it manually unless you tweak the file
>> "/var/lib/logrotate.status" first.
>> 
>> Note also that httpd exited within the window for logrotate, which
>> also seems to point the finger at logrotate, so I'd definitely make
>> sure that was in tonight's list of disabled scripts, and it might be
>> worth double checking what update cycle certwatch is using too.
>> 
>> Andy
>> ___
>> users mailing list -- users@lists.fedoraproject.org
>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: HTTPD shutting down every night

[Scott van Looy via users]

Thanks for this.

Certwatch is uninstalled now, it just tells me if any of my certs have expired 
and as I don’t have any on that box any more it’s kinda pointless :)

I’ve removed the stuff to hide the output from the apache restart in logrotate 
so I’m going to let it run tonight and see if anything exciting gets logged

Regards,

Scott

> On 12. Nov 2018, at 16:08, Andy Blanchard  wrote:
> 
> Of that bunch, autodld (downloading RPMs) and rkhunter (scanning the
> filesystem, taking checksums, and looking for changes) are both
> passive, certwatch probably shouldn't be updating certificates every
> 24 hours (but could do, so worth checking!), and logwatch just parses
> the existing logfiles - it shouldn't touch the daemons.  That leaves
> logrotate as the prime suspect, IMHO, as that definitely HUPs/restarts
> daemons after it rotates logfiles.  However, it also tracks when it
> was last run and won't cycle a logfile and HUP a daemon if it doesn't
> need to - since it's already cycled the logs at 03:54, it won't do so
> again when you're trying to run it manually unless you tweak the file
> "/var/lib/logrotate.status" first.
> 
> Note also that httpd exited within the window for logrotate, which
> also seems to point the finger at logrotate, so I'd definitely make
> sure that was in tonight's list of disabled scripts, and it might be
> worth double checking what update cycle certwatch is using too.
> 
> Andy
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: HTTPD shutting down every night

[Scott van Looy via users]

Still restarting.

Today the log reads:

[Mon Nov 12 03:54:57.152381 2018] [mpm_event:notice] [pid 9721:tid 
140481219127552] AH00492: caught SIGWINCH, shutting down gracefully

Checking the cron log:

Nov 12 03:54:49 novak run-parts[81241]: (/etc/cron.daily) finished 0logwatch
Nov 12 03:54:49 novak run-parts[81241]: (/etc/cron.daily) starting autodld
Nov 12 03:54:49 novak run-parts[81241]: (/etc/cron.daily) finished autodld
Nov 12 03:54:49 novak run-parts[81241]: (/etc/cron.daily) starting certwatch
Nov 12 03:54:55 novak run-parts[81241]: (/etc/cron.daily) finished certwatch
Nov 12 03:54:55 novak run-parts[81241]: (/etc/cron.daily) starting logrotate
Nov 12 03:54:58 novak run-parts[81241]: (/etc/cron.daily) finished logrotate
Nov 12 03:54:58 novak run-parts[81241]: (/etc/cron.daily) starting rkhunter

Tried running them individually, nothing seems to stop httpd. I’ve disabled a 
few so I’ll see what happens tonight. Again, if anyone has any suggestions, 
it’d be great to try some stuff!

Regards,

Scott

> On 11. Nov 2018, at 11:50, Scott van Looy via users 
>  wrote:
> 
> Thanks for this.
> 
> I noticed last night that both https and bind had been killed and failed to 
> restart so I’m beginning to suspect maybe there’s a memory problem somewhere 
> in the log rotate stuff - but I’m not sure.
> 
> Lots of updates came down today, hoping it might magically fix itself :)
> 
> Fun!
> 
> Scott
> 
>> On 11. Nov 2018, at 11:27, Andy Blanchard  wrote:
>> 
>> Just upgraded a box to 29, and I've spotted the following in the httpd
>> section of my Logwatch email:
>> 
>> Unescaped left brace in regex is deprecated here (and will be fatal
>> in Perl 5.32), passed through in regex; marked by <-- HERE in m/\G%({
>> <-- HERE .*?})?./ at /usr/share/logwatch/scripts/services/http line
>> 319.
>> 
>> It does, however, appear to have successfully rotated the httpd
>> logfiles and restated httpd without incident, but may be a pointer as
>> to what might be going wrong on your server.
>> 
>> Andy
>> ___
>> users mailing list -- users@lists.fedoraproject.org
>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: HTTPD shutting down every night

[Scott van Looy via users]

Thanks for this.

I noticed last night that both https and bind had been killed and failed to 
restart so I’m beginning to suspect maybe there’s a memory problem somewhere in 
the log rotate stuff - but I’m not sure.

Lots of updates came down today, hoping it might magically fix itself :)

Fun!

Scott

> On 11. Nov 2018, at 11:27, Andy Blanchard  wrote:
> 
> Just upgraded a box to 29, and I've spotted the following in the httpd
> section of my Logwatch email:
> 
> Unescaped left brace in regex is deprecated here (and will be fatal
> in Perl 5.32), passed through in regex; marked by <-- HERE in m/\G%({
> <-- HERE .*?})?./ at /usr/share/logwatch/scripts/services/http line
> 319.
> 
> It does, however, appear to have successfully rotated the httpd
> logfiles and restated httpd without incident, but may be a pointer as
> to what might be going wrong on your server.
> 
> Andy
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Re: HTTPD shutting down every night

[Scott van Looy via users]

OK thanks for this.

It’s not normal though, it doesn’t actually restart - it just crashes.

/bin/systemctl reload httpd seems to work OK when I run it as root, the server 
restarts.

So I’m still a little confused. Does anyone have any suggestions?

> On 7. Nov 2018, at 15:52, Roger Heflin  wrote:
> 
> this is the daily logrotate process.  it rotates the log files and
> reloads httpd.  It is normal.   A number of other process will also
> restart at the same time.
> 
> See:
> cat /etc/logrotate.d/httpd
> /var/log/httpd/*log {
>missingok
>notifempty
>sharedscripts
>delaycompress
>postrotate
>/bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
>endscript
> }
> On Wed, Nov 7, 2018 at 5:53 AM Andy Blanchard  wrote:
>> 
>> On Wed, 7 Nov 2018 at 10:40, Scott van Looy via users
>>  wrote:
>>> Since the upgrade to F29 my HTTPD has been shutting down around 3am every 
>>> night. I’d like to try and investigate why, but the only thing in the log 
>>> is:
>>> [mpm_event:notice] [pid 1096508:tid 140027704744192] AH00492: caught 
>>> SIGWINCH, shutting down gracefully
>>> 
>>> These all happen at roughly the same time, but not the exact same time - 
>>> around 3am
>> 
>> Semi-regular times like "around 3am" generally imply something being
>> governed by Anacron's variable task scheduler which will randomise the
>> time of cron jobs.  Since this is daily, I'd start by taking a look at
>> your daily crons and see if any of them might relate to the issue -
>> most likely a log rotation tool or something along those lines.
>> 
>> SIGWINCH isn't one of the more common signals you'll interact with
>> like TERM, but it supposedly relates to "WINdow CHange", or a change
>> in the size of the controlling terminal's window size - e.g. to tell a
>> shell like bash that the terminal emulator window has been resized and
>> it now needs to wrap at a different number of characters.  However it
>> seems Apache doesn't use it entirely correctly so it may be that your
>> log rotation tool is actually stopping the daemon rather than HUPing
>> it as it should.
>> 
>> Andy
>> ___
>> users mailing list -- users@lists.fedoraproject.org
>> To unsubscribe send an email to users-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

HTTPD shutting down every night

[Scott van Looy via users]

Hi,

Since the upgrade to F29 my HTTPD has been shutting down around 3am every 
night. I’d like to try and investigate why, but the only thing in the log is:
[mpm_event:notice] [pid 1096508:tid 140027704744192] AH00492: caught SIGWINCH, 
shutting down gracefully

These all happen at roughly the same time, but not the exact same time - around 
3am

It’s strange

Scott
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org