Nginx + Syslog Question

2022-04-16 Thread David Anthony

Hello List,

I'm trying to send Nginx access logs to syslog. I've tried examples in 
the default nginx configuration file and man page to no avail. Can 
anyone help identify why I'm not seeing access logs?


Respectfully,

David Anthony

- - -

*syslog.conf*

|*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
kern.debug;syslog,user.info /var/log/messages
auth.info /var/log/authlog
authpriv.debug /var/log/secure
cron.info /var/cron/log
daemon.info /var/log/daemon
ftp.info /var/log/xferlog
lpr.debug /var/log/lpd-errs
mail.info /var/log/maillog

|

*nginx.conf*

error_log syslog:server=unix:/dev/log,severity=notice;
worker_processes 1;
worker_rlimit_nofile 1024;
user www;

events {
    worker_connections 800;
}

http {
    include mime.types;
    default_type application/octet-stream;
    keepalive_timeout 65;
    server_tokens off;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
    '$status $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  syslog:server=unix:/dev/log,severity=debug main;

    server {
    listen 80 default_server;
    server_name _;
    location / {
/            REMOVED/
    }
    }
}



Zabbix 6.0.3 with Postgresql 14.2 on OpenBSD 7.1 stops graphing after two hours

2022-04-16 Thread Noth

Hi,

  I built the new 7.1 packages for Zabbix and PostgreSQL, and upgraded 
my monitoring VM. To my horror the zabbix_server process stops graphing 
after a couple of hours of uptime, with the housekeeper and history 
syncer processes at over 80% cpu usage. PostgreSQL shows INSERT 
processes stuck at 80% too, and restarting zabbix_server hangs, leaving 
zombie processes. I was using 2 vcpus and 2G of RAM. Feeling that the 
login.conf limits might be the problem I uped them by quite a bit:


postgresql:\
-:openfiles=1024:\
+:openfiles=4096:\
 :tc=daemon:
:datasize-max=2048M:\
:datasize-cur=2048M:\

I also uped sysctls:

-kern.seminfo.semmns=2048
-kern.shminfo.shmall=1024512
+kern.seminfo.semmns=4096
+kern.shminfo.shmall=1572864

This helped quite a bit, the graphing at least doesn't stop. Yet the housekeeper 
& history sync processes are still stuck continuously at over 80%. I even 
doubled the RAM to 4G and the vcpus to 4. Yet this is what top shows:

CPU0 states: 82.4% user,  0.0% nice, 14.7% sys,  1.0% spin,  0.0% intr,  2.0% 
idle
CPU1 states: 79.4% user,  0.0% nice,  9.8% sys,  0.0% spin,  0.0% intr, 10.8% 
idle
CPU2 states: 80.4% user,  0.0% nice,  9.8% sys,  0.0% spin,  0.0% intr,  9.8% 
idle
CPU3 states: 94.1% user,  0.0% nice,  4.9% sys,  0.0% spin,  0.0% intr,  1.0% 
idle
Memory: Real: 738M/2131M act/tot Free: 1796M Cache: 1091M Swap: 0K/2055M

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
48835 _postgre  640  307M  247M onproc/0  -23.4H 98.24% postgres: 
zabbix zabbix [local] SELECT
42079 _postgre  640  307M  245M run/2 -25.3H 98.10% postgres: 
zabbix zabbix [local] SELECT
 3630 _postgre  630  308M  282M onproc/1  -21.2H 82.42% postgres: 
zabbix zabbix [local] DELETE
12622 _postgre  600  307M  127M onproc/2  -20.8H 79.10% postgres: 
zabbix zabbix [local] INSERT

None of this behaviour happened with versions 2.x through to 5.x. Yes 
I've followed the pkg-readme for both PostgreSQL and Zabbix. Maybe these 
need adjusting? I'm at a loss on what I need to tune to make everything 
go back to being running with low CPU usage. I am fully aware 6.x now 
collects data points of a gazillion more things (so many entries with 
just $1 as the name now, I'm not sure what's going on there).


Hopefully some of you have an idea, cheers,

Noth

OpenBSD 7.1 (GENERIC.MP) #1: Wed Apr  6 18:48:24 CEST 2022
r...@builder2.nineinchnetworks.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4255670272 (4058MB)
avail mem = 4109398016 (3919MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xbfbcb000 (13 entries)
bios0: vendor BHYVE version "13.0" date 11/10/2020
bios0: FreeBSD BHYVE
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S5
acpi0: tables DSDT FACP HPET APIC MCFG SPCR
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 16777216 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3408.57 MHz, 06-9e-0d
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,HLE,AVX2,BMI2,ERMS,INVPCID,RTM,RDSEED,MD_CLEAR,ARAT,XSAVEOPT,MELTDOWN

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 134MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3413.28 MHz, 06-9e-0d
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,HLE,AVX2,BMI2,ERMS,INVPCID,RTM,RDSEED,MD_CLEAR,ARAT,XSAVEOPT,MELTDOWN

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 0, package 1
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3411.94 MHz, 06-9e-0d
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,SDBG,FMA3,CX16,xTPR,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,ITSC,FSGSBASE,BMI1,HLE,AVX2,BMI2,ERMS,INVPCID,RTM,RDSEED,MD_CLEAR,ARAT,XSAVEOPT,MELTDOWN

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 0, package 2
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Xeon(R) E-2278G CPU @ 3.40GHz, 3419.69 MHz, 06-9e-0d
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA

Re: Resource temporarily unavailable: have to recompile?

2022-04-16 Thread Luke Call
> - Forwarded message from Strahil Nikolov  -
> From: Strahil Nikolov 
> To: "Luke A. Call" , misc@openbsd.org
> Subject: Re: Resource temporarily unavailable: have to recompile?
> On February 1, 2020 12:27:40 AM GMT+02:00, "Luke A. Call" 
>  wrote:
> >I am still seeing this problem, even after logging out/in and ulimit -u
> >shows 712.   Running "ps -U myusername|less" yields about 180 lines and
> >the system becomes unable to start even another xterm, or in tmux on a
> >console, unable to start another shell window (in both cases: "Resource
> >temporarily unavailable").
> >
> >On 01-31 13:20, Luke A. Call wrote:
> >> Am I running into a limit that will require recompiling the kernel
> >> (or changing my work style I suppose)?  Which man pages should I read
> >> next, or should I be thinking about this differently?
> >> 
> >> I am getting "Resource temporarily unavailable" in
> >> /var/log/authlog when I try to open too many "ssh [-X]
> >user@localhost"
> >> connections, or even "fork: retry: Resource temporarily unavailable"
> >when
> >> running "$ cat > /tmp/somefile".  
> >> 
> >> In "man 3 __tfork" I see:
> >> [EAGAIN]Resource temporarily unavailable.  The system-imposed
> >>limit on the total number of threads under execution
> >>would be exceeded.  This limit is configuration-
> >>dependent.
> >> 
> >> [EAGAIN]Resource temporarily unavailable.  The system-imposed
> >>limit MAXUPRC on the total number of threads under
> >>execution by a single user would be exceeded.  MAXUPRC
> >>is currently defined in  as CHILD_MAX,
> >>which is currently defined as 80 in .
> >> 
> >> (If multiple users could simultaneously run X, I might not ssh as
> >much;
> >> suggestions welcome there also, if you are in the mood.)
> >> 

> Hi  Luke,
> Have you tried to reuse  ssh connections.
> In linux you can use something like this:
> ControlMaster auto 
> ControlPath ~/.ssh/sockets/%r@%h-%p
> ControlPersist 600
> 
> I guess it's  still valid for openBSD.

Hi. Sorry so late at this, but replying to thank you for your suggestions, 
Strahil.

I finally figured out (again, it has been a while, I just failed to reply)
that (I think) I needed to (again?) increase maxproc-cur for the default
login class (per id -c), in /etc/login.conf and log back in.  I have had to do
that again after upgrading to 6.9 and 7.0 also, for several values, but 
fortunatly
the email from sysmerge prompted me in a way.  And now I can open as many
terminal windows as I want.

I also don't ssh as much locally, now that I understand xauth better,
thanks to info such as found in Part 8 of:
  https://www.exoticsilicon.com/jay/reckless_guide_to_openbsd/
...and very helpful pointers from Crystal Kolipe.

All the best,
--
Luke Call
* Are info sources trustworthy?  How do we know?  Based on identifying, and
  observing trustworthy behavior over time, of the original eyewitness, and
  all reporters in the chain to us?  And corroboration by other such?
* Happy to discuss, or: http://lukecall.net - Tech, many thots, peace amid 
commotion, fun. (Cmts/sugg welcome. https later.)