Re: Best way to increase openfiles-max and -cur for NGINX/PHP?

2021-01-16 Thread Unicorn
Todd C. Miller wrote:
> Error 24 is EMFILE, too many open files for the process (not the
> system).
> [...]
> That would only work if you were getting error 23, ENFILE which is
> the system limit.

Thank you for pointing that out! So it was the login.conf afterall.

> The recommended way to increase a limit is to add a new login class
> with the same name as the daemon.  For example:
> 
> nginx:\
> :openfiles=4096:\
> :tc=daemon:
> 
> This will be used automatically by the rc.d startup script.  See
> the rc.d man page for more details.

Wow, I would not have thought to look at the bottom of the rc.d man
page, thank you so much for mentioning that! I did what you suggested
for php73_fpm in my case and it works like a charm, no more errors.
Thank you!


Marc Peters wrote:
> If you really ran into problems with nginx and php_fpm while running
> nextcloud, you could either do this or change the user the service 
> use and assign this user the daemon class or some special class.
> I am running a similar setup with the default configuration and no
> issues (since a week i use php-7.4, but had 7.3 before)

This occurred when scrolling top to bottom in a folder of 200+ images,
perhaps you don't usually have that kind of use? Either way I managed
to reproduce the errors by repeating this procedure, so I am pretty
sure it was the cause. Cranking up the openfiles limit for php73_fpm
did end up making the errors disappear.


Maurice McCarthy wrote:
> Have a look at man ksh - the section on the command "ulimit".

I was actually looking for a ulimit manpage but was unsuccessful -
thanks for pointing out it is part of ksh(1)!




Best way to increase openfiles-max and -cur for NGINX/PHP?

2021-01-16 Thread Unicorn
Hello,

I am getting a bunch of error messages of this kind in my NGINX error
log:

2021/01/16 13:40:45 [alert] 68769#0: *1 socket() failed (24: Too many
open files) while connecting to upstream, client: 123.45.67.89,
server: cloud.mydomainhere.tld, request: "GET /core/preview?blah=1
HTTP/2.0", upstream: "fastcgi://127.0.0.1:9000", host:
"cloud.mydomainhere.tld"

I am running a Nextcloud server with NGINX and PHP 7.3. Since OpenBSD
Is quite conservative with open file limits by default, I assume that
NGINX/PHP is running into this limit.

I have already significantly increased 'kern.maxfiles' in sysctl.conf,
but the problem persists after a reboot, leading me to believe that it
is a login.conf limit that I am running into.

Both PHP and NGINX are running as user 'www', which does not have a
login class. Since I have not been in this situation before and
struggled to find a pointer online, I'd be thankful if you could tell
me the "recommended" or "best practice" way of doing this. 

- Should I simply assign a login class to user 'www' and then change
my limits through that class?
- Should I run the processes as a different user & login class?
- Is there perhaps some other way to set limits just for specific
processes?

Thanks in advance for any pointers!



Re: Relayd "cannot load certificates" when using 2 'listen' statements in a relay

2020-12-20 Thread Unicorn
Sorry for the duplicate post, I now saw that this question has been
asked previously. I am sadly also not able to test the diff that was
provided in one of the previous threads.

I have split the relay into two relays with one `listen` statement
each for now, which works fine.

Best,
Unicorn



Relayd "cannot load certificates" when using 2 'listen' statements in a relay

2020-12-19 Thread Unicorn
Hello,

I am just figuring out relayd and am trying to make it listen both on
my ipv4 and ipv6 address. I have specified them with these macros:
```
$ext_ipv4 = "blah"
$ext_ipv6 = "expandedblah"
```


Then I have this relay with the two listen statements, to listen on
ipv4 and ipv6:
```
relay "proxy_secure" {
listen on $ext_ipv4 port 443 tls
listen on $ext_ipv6 port 443 tls

protocol "https"

forward to  port 1001
forward to  port 1002
}
```


Finally, this is the relevant part of the "https" protocol:
```
http protocol "https" {
...
tls keypair "firstdomain.tld"
tls keypair "seconddomain.tld"
}
```


With both listen statements, 'relayd -n' throws this error:

"/etc/relayd.conf:58: cannot load certificates for relay
proxy_secure4:443"

Removing either of the 'listen' statements resolves this issue, but
that would mean listening only on ipv4 OR ipv6. How could I solve this
issue? Am I missing something obvious? The manpage makes me believe
that having two 'listen' statements in a single relay is not an issue
per se, so why is relayd unhappy with this specific configuration?

I'd be very thankful for your guidance. :)

Best,
Unicorn



Nextcloud large file downloads fail (httpd, postgresql, php7.3)

2020-09-22 Thread Unicorn
Hello,

I have been encoutering this issue on several machines and have not
been able to locate the cause even after days worth of searching, let
alone find a solution (although I tried many things).

Basically, downloading a large file (1.2GB Video in this case) through
my web browser simply fails once a certain amount as been downloaded.
On one of my machines (4GB RAM) this happens around the 800MB-1GB
mark, on another (2GB RAM) this happens around the 400-500MB mark.

I have tried increasing PHP's memory_limit, max_input_time,
max_execution_time, post_max_size, upload_max_filesize and
opcache.memory_consumption, to no avail.

I have set the following values similar to the example httpd.conf in
the pkg-readme for nextcloud, additionally increasing the max request
body from 513M to 4GB (although it fails similarly with both):

# Set max upload size to 4GB (in bytes)
connection max request body 4294967296
connection max requests 1000
connection request timeout 3600
connection timeout 3600

My only clue was the difference between the two machines being roughly
proportional to their RAM size, but I do not understand this since I
only observed RAM usage of around 50% by httpd (observed with ps aux).

I am simply running out of ideas and struggling to find the cause of
the issue, so I would appreciate any advice or places/settings/logs to
look for an answer.

Please let me know if you need additional information to help me, I am
happy to provide it!

Best,
Unicorn



Re: /etc/netstart fails on first attempt, works on second

2020-09-20 Thread Unicorn
On Sat, 2020-09-19 at 17:36 +0200, Unicorn wrote:
> On Sat, 2020-09-19 at 14:18 +0100, Tom Smyth wrote:
> > Hi Unicorn,
> > 
> > what do you have in in your em0 config
> > /etc/hostname.em0
> 
> Hi, the contents are just this, to reduce the possibility of errors
> on
> my part for now:
> 
> dhcp
> inet6 autoconf
> 
> > are you in control of the KVM infrastructure ?  can you get a
> > vio  nic instead of a intel 1000 nic   it will generally perform
> > better (according to my humble testing)
> > 
> > Hope this helps
> > 
> > Tom Smyth
> 
> Thanks for the advice! I am not in control of the KVM infrastructure
> but the support has previously been nice enough to change the
> storage
> driver for me as it was also causing issues with OpenBSD (it was
> virtio-scsi that was causing issues iirc).
> I will ask them to change to virtio for networking and report back
> once it's done.
> 
> Best,
> Unicorn

Indeed, switching to Virtio (and renaming /etc/hostname.em0 to
/etc/hostname.vio0) solved my issue, it now works correctly at boot.

Thank you for your help!

Best, Unicorn



Re: /etc/netstart fails on first attempt, works on second

2020-09-19 Thread Unicorn
On Sat, 2020-09-19 at 14:18 +0100, Tom Smyth wrote:
> Hi Unicorn,
> 
> what do you have in in your em0 config
> /etc/hostname.em0

Hi, the contents are just this, to reduce the possibility of errors on
my part for now:

dhcp
inet6 autoconf

> are you in control of the KVM infrastructure ?  can you get a
> vio  nic instead of a intel 1000 nic   it will generally perform
> better (according to my humble testing)
> 
> Hope this helps
> 
> Tom Smyth

Thanks for the advice! I am not in control of the KVM infrastructure
but the support has previously been nice enough to change the storage
driver for me as it was also causing issues with OpenBSD (it was
virtio-scsi that was causing issues iirc).
I will ask them to change to virtio for networking and report back
once it's done.

Best,
Unicorn



/etc/netstart fails on first attempt, works on second

2020-09-18 Thread Unicorn
Hello,

First of all I apologize to the list manager for posting this without
a subject line before, I overlooked it.

I am encountering a network related issue in a KVM VPS that I am using
for OpenBSD. The way it appears to me is that /etc/netstart fails to
get a network connection using dhcp on its first attempt, but works on
the second attempt.

While the system is booting, I see the following:
> em0: no link. sleeping

However, executing 'sh /etc/netstart' once the system is booted works:
> em0: 123.123.123.123 lease accepted from [...]

The same happened during first installation of OpenBSD, I just told it
to use dhcp, it fails the first time, but works if I just do the same
thing for the same interface again.

Attached is the full output of dmesg, I attached it as a plain text
file due to the line breaks hindering readability in email.
I would appreciate any pointers as to what is happening and how I
could fix it or work around it.

Thanks a lot in advance!
OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020 
   
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
   
real mem = 4278165504 (4079MB)  
   
avail mem = 4135882752 (3944MB) 
   
mpath0 at rootscsibus0 at mpath0: 256 targets   
 
mainbus0 at root
   
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf61e0 (13 entries)   
   
bios0: vendor Seabios version "0.5.1" date 01/01/2011   
   
bios0: Red Hat KVM  
   
acpi0 at bios0: ACPI 1.0
   
acpi0: sleep states S5  
   
acpi0: tables DSDT FACP SSDT APIC   





acpi0: wakeup devices   
   
acpitimer0 at acpi0: 3579545 Hz, 24 bits
   
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
   
cpu0 at mainbus0: apid 0 (boot processor)   
   
cpu0: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 180.94 MHz, 06-4f-01   
   
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,XSAVEOPT,MELTDOWN


cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache 
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped 
   
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped 





cpu0: smt 0, core 0, package 0  
   
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges   
   
cpu0: apic clock running at 999MHz  
   
cpu1 at mainbu

[no subject]

2020-09-18 Thread Unicorn
Hello,

I am encountering a network related issue in a KVM VPS that I am using
for OpenBSD. The way it appears to me is that /etc/netstart fails to
get a network connection using dhcp on its first attempt, but works on
the second attempt.

While the system is booting, I see the following:
> em0: no link. sleeping

However, executing 'sh /etc/netstart' once the system is booted works:
> em0: 123.123.123.123 lease accepted from [...]

The same happened during first installation of OpenBSD, I just told it
to use dhcp, it fails the first time, but works if I just do the same
thing for the same interface again.

Attached is the full output of dmesg, I attached it as a plain text
file due to the line breaks hindering readability in email.

I would appreciate any pointers as to what is happening and how I
could fix it or work around it.

Thanks a lot in advance!
OpenBSD 6.7 (GENERIC.MP) #182: Thu May  7 11:11:58 MDT 2020 
   
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
   
real mem = 4278165504 (4079MB)  
   
avail mem = 4135882752 (3944MB) 
   
mpath0 at rootscsibus0 at mpath0: 256 targets   
 
mainbus0 at root
   
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf61e0 (13 entries)   
   
bios0: vendor Seabios version "0.5.1" date 01/01/2011   
   
bios0: Red Hat KVM  
   
acpi0 at bios0: ACPI 1.0
   
acpi0: sleep states S5  
   
acpi0: tables DSDT FACP SSDT APIC   





acpi0: wakeup devices   
   
acpitimer0 at acpi0: 3579545 Hz, 24 bits
   
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
   
cpu0 at mainbus0: apid 0 (boot processor)   
   
cpu0: Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 180.94 MHz, 06-4f-01   
   
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,XSAVEOPT,MELTDOWN


cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 
16-way L2 cache 
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped 
   
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped 





cpu0: smt 0, core 0, package 0  
   
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges   
   
cpu0: apic clock running at 999MHz  
   
cpu1 at mainbus0: apid 1 (application processor)
   
cpu

OpenBSD 6.7 Virtio disk not recognized during install

2020-06-17 Thread Unicorn
Hello!

I have been running OpenBSD 6.6 on three KVM VPS for months and was
able to install without issues all three times. Now however, when
trying to install either OpenBSD 6.6 or 6.7 on another VPS, the
virtual disk is not recognized by the installer.

Running `sysctl hw.disknames` just gives me cd0 and rd0, but no sd0
device. I do know for sure that the device exists though because there
is a running Debian 10 installation on it that I can choose to boot
from. Looking through my `dmesg`, I see these lines containing "not
configured":

```
acpicpu at acpi0 not configured
"ACPI0006" at acpi0 not configured
"PNP0A03" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured"Intel 
82801AA AC97" rev 0x01 at pci0 dev 4 function 0 not configured
virtio1: no matching child driver; not configured
uhid at uhidev0 not configured```

When I do `dmesg | grep "not configured"` on my other running OpenBSD
VPS installations, I only get a third of these "* not configured"
messages and the installation worked fine for the most part. The KVM-
related settings that the VPS hosting company provides are identical
between my different installations, so I don't know what could be the
cause of this.

In case it helps, I will just list the different settings they
provide:
ACPI (checkbox)
APIC (checkbox)
Activate Virtio (checkbox)
Virtual Network Card (Intel E1000 or Realtek 8139 or Virtio)

All three checkboxes are enabled and Intel E1000 selected as default
network card.

I would very much appreciate any hints on what may be causing my issue
and how to work around it. I apologize if part of my problem looks
obvious to you, I simply don't have the experience and my searches
couldn't help me figure it out. Thank you in advance!



Re: Updating a Nextcloud instance installed via package

2020-04-18 Thread Unicorn
> I keep a nightly backup of the database (postgres in my case),
> upgrade packages and trigger nextcloud's upgrade process via HTTPS
> on the nextcloud login page. This process has not failed for me so
> far. Except when postgres had a version bump as well with some
> incompatible DB format changes, and I stupidly upgraded postgres
> without checking whether my DB backup was current. Turned out it was
> a day or so behind. But I could restore this DB backup to a newly
> created postgres database and nextcloud kept working.

Thanks a ton for the input, I will give this procedure a shot!

Since I am also using postgres and don't have much experience working
with databases, I would appreciate advice on backing up postgres. Do
you use the syntax from the NC docs (
https://docs.nextcloud.com/server/18/admin_manual/maintenance/backup.html#backup-database
) with something like a cron job, or would you advise something
different/additional?

Thanks again for your help!





Updating a Nextcloud instance installed via package

2020-04-17 Thread Unicorn
Hello,

I have a running installation of Nextcloud, installed via the OpenBSD
package and set up according to the various pkg-readmes. The section
about updating is kept very short, so I wanted to ask here before doing
something unwise out of my lack of experience:

When trying to use the NC updater (after working around the chroot), it
complains that there is an additional file in the directory, namely
".htaccess.dist". The installation also fails the integrity check
(unrelated to upgrade), I assume because of modifications that were
made by the maintainers. I am not aware of what these modifications are
and whether they are needed for NC to run properly on OpenBSD, so I was
wondering how the update process would work using "pkg-add -u" to
simply update the package. Would that replace the entire directory, or
does it just fetch the newest version of Nextcloud, after which I would
just need to run `occ upgrade`? Is there a better, recommended way to
update in this case?

I'd be very thankful for some guidance and advice before I accidentally
break something or end up with a bad hack. :)

Regards,
Unicorn



Re: Disabling laptop display & turning off suspend on lid close

2019-11-22 Thread Unicorn
On Fri, 2019-11-22 at 09:53 +0100, Gabriel Kihlman wrote:
> Unicorn  writes:
> > Still would like to know how to turn the display off, have not
> > figured
> > that out yet ;)
> 
> If you are not starting X, this is enough:
> 
> $ cat /etc/wsconsctl.conf 
> display.screen_off=10
> display.vblank=on
> display.kbdact=on
> display.msact=on
> display.outact=off
> 
> See the FAQ (Blanking an Inactive Console):
> https://www.openbsd.org/faq/faq7.html
> 
> Excerpt for your convenience:
> 
> "
> display.screen_off determines the blanking time in milliseconds.
> display.kbdact if set to on, keyboard activity will unblank the
> screen.
> display.msact if set to on, console mouse activity will unblank the
> screen.
> display.outact if set to on, screen output will unblank the screen.
> display.vblank if set to on will disable the vertical sync pulse.
> This will cause many monitors to go into an energy saver mode.
> "
> 
> /gabriel
> 

> Have a look at wsconsctl.conf(5).  Might be relevant.
> 
> -- 
> 
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> 

Thank you, this is what I was looking for! :)

I am sorry for not mentioning that I am not running X and not intending
to.

I did search online (only finding X related solutions) and stumbled
upon wsdisplay after searching through manpages for a while, but there
was too much terminology and system knowledge that I did not know about
for me to conclude what exactly I need to do. Next time I will try to
include more context to avoid confusion though. :)

Thanks again and all the best,

Unicorn





Re: Disabling laptop display & turning off suspend on lid close

2019-11-22 Thread Unicorn
On Fri, 2019-11-22 at 09:28 +0100, Claus Assmann wrote:
> On Fri, Nov 22, 2019, Unicorn wrote:
> 
> > Still would like to know how to turn the display off, have not
> > figured
> > that out yet ;)
> 
> man xset
> 
> Not sure if this is what you want (yes, it's ugly):
> 
> #!/bin/sh
> if test $# -ge 1
> then
>   TO=$1
> else
>   TO=300
> fi
> xset s $TO
> xset s blank
> if test $# -lt 1
> then
> xset dpms 500 660 900
> fi
> 

Thank you for the suggestion!

Will using xset work without running X? I intended to not use X as I am
just trying to set up a simple mailserver. :)

Best,

Unicorn



Re: Disabling laptop display & turning off suspend on lid close

2019-11-22 Thread Unicorn
On Fri, 2019-11-22 at 09:05 +0100, Unicorn wrote:
> Hello,
> 
> I am currently setting up my ThinkPad X220 as a server running
> OpenBSD
> and wish to disable the integrated display as it is anyway and will
> not
> be used.
> 
> Equally, I wish for the ThinkPad to not suspend when I close the lid,
> as the lid will be closed practically all the time. :)
> 
> I am not familiar with how the underlying systems work so I had
> trouble
> figuring out a solution myself, and searching online sadly did not
> give
> me working results. Any help is thus greatly appreciated!
> 
> Best,
> 
> Unicorn

Okay, by trial and error I found the sysctl setting machdep.lidaction=0
turns off suspend on closing lid, and I figured out I need to add it to
/etc/sysctl.conf to make it permanent, so I'm sorry for the early
question about that :)

Still would like to know how to turn the display off, have not figured
that out yet ;)

Best,

Unicorn



Disabling laptop display & turning off suspend on lid close

2019-11-22 Thread Unicorn
Hello,

I am currently setting up my ThinkPad X220 as a server running OpenBSD
and wish to disable the integrated display as it is anyway and will not
be used.

Equally, I wish for the ThinkPad to not suspend when I close the lid,
as the lid will be closed practically all the time. :)

I am not familiar with how the underlying systems work so I had trouble
figuring out a solution myself, and searching online sadly did not give
me working results. Any help is thus greatly appreciated!

Best,

Unicorn



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Unicorn
On Sun, 2019-11-17 at 23:22 +0300, Consus wrote:
> On 16:25 Sun 17 Nov, Unicorn wrote:
> > After installing redis (and rspamd), before having modified any
> > part of
> > redis, starting redis with 'rcctl start redis' fails. I then tried
> > running the binary itself in /usr/local/sbin/redis-server, which
> > only
> > returns 'Bus error (core dumped)'.
> > 
> > I changed the log level in the '/etc/redis/redis.conf' to debug,
> > but do
> > not get any more information about the reason for failure. Running
> > 'grep -R redis /var/log/' did not give me any information either,
> > and
> > after changing the log level to debug, the only thing that changed
> > is
> > an unreadable 'redis-server.core' file appearing in '/var/log'.
> 
> Please, post the output of
> 
>   # gdb /usr/local/sbin/redis-server /var/log/redis-server.core
> 

Output:

GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "arm-unknown-openbsd6.6"...(no debugging
symbols found)

Core was generated by `redis-server'.
Program terminated with signal 10, Bus error.
(no debugging symbols found)
Loaded symbols for /usr/local/sbin/redis-server
Reading symbols from /usr/lib/libm.so.10.1...done.
Loaded symbols for /usr/lib/libm.so.10.1
Reading symbols from /usr/lib/libpthread.so.26.1...done.
Loaded symbols for /usr/lib/libpthread.so.26.1
Reading symbols from /usr/local/lib/liblua5.1.so.5.1...done.
Loaded symbols for /usr/local/lib/liblua5.1.so.5.1
Reading symbols from /usr/lib/libc.so.95.1...done.
Loaded symbols for /usr/lib/libc.so.95.1
Reading symbols from /usr/libexec/ld.so...Error while reading shared
library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be
2) [in module /usr/libexec/ld.so]
#0  0x133f3834 in SHA1Final () from /usr/local/sbin/redis-server
(gdb) 



Re: Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Unicorn
On Sun, 2019-11-17 at 16:25 +0100, Unicorn wrote:
> Hello again,
> 
> I am currently setting up redis with rspamd for my mail setup, but I
> am
> encountering an issue when trying to just start redis.
> For the record, I am following the guide at 
> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
> 
> After installing redis (and rspamd), before having modified any part
> of
> redis, starting redis with 'rcctl start redis' fails. I then tried
> running the binary itself in /usr/local/sbin/redis-server, which only
> returns 'Bus error (core dumped)'.
> 
> I changed the log level in the '/etc/redis/redis.conf' to debug, but
> do
> not get any more information about the reason for failure. Running
> 'grep -R redis /var/log/' did not give me any information either, and
> after changing the log level to debug, the only thing that changed is
> an unreadable 'redis-server.core' file appearing in '/var/log'.
> 
> I'd very much appreciate your help, thanks in advance!
> 
> Best,
> 
> Unicorn
> 

I forgot to mention that I am running redis on ARMv7, and I think the
issue is that something is broken with ARMv7 and Redis, since it worked
just fine inside a VM on x86_64.

Is there anything I can do to fix this or diagnose it further?

Would really appreciate any suggestions. :)

Best,

Unicorn



Starting redis fails with 'Bus error (core dumped)'

2019-11-17 Thread Unicorn
Hello again,

I am currently setting up redis with rspamd for my mail setup, but I am
encountering an issue when trying to just start redis.
For the record, I am following the guide at 
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/

After installing redis (and rspamd), before having modified any part of
redis, starting redis with 'rcctl start redis' fails. I then tried
running the binary itself in /usr/local/sbin/redis-server, which only
returns 'Bus error (core dumped)'.

I changed the log level in the '/etc/redis/redis.conf' to debug, but do
not get any more information about the reason for failure. Running
'grep -R redis /var/log/' did not give me any information either, and
after changing the log level to debug, the only thing that changed is
an unreadable 'redis-server.core' file appearing in '/var/log'.

I'd very much appreciate your help, thanks in advance!

Best,

Unicorn



Re: Cron not executing @reboot command in crontab

2019-11-17 Thread Unicorn
> At the top of the file you'll see:
> 
>   PATH=/bin:/sbin:/usr/bin:/usr/sbin
> 
> Either {pre,ap}pend /usr/local/{,s}bin or use the full command path.
> 
> Regards,
> 
> Raf
> 

> Use a full path. cran has a very limited default PATH.
>
>   -Otto


Thank you both, it works perfectly now!

Best,

Unicorn



Cron not executing @reboot command in crontab

2019-11-17 Thread Unicorn
Hello,

I apologize if this is trivial, I genuinely read through all the cron-
related manpages and tried several things, but this is my issue:

I want to use 'autossh' to automatically establish reverse port
forwarding on boot, so (as root) I can 'crontab -e' and added this line
to the bottom:

@reboot autossh [all my options]

After adding the line, running 'crontab -l' shows that the line was
correctly added; I have also confirmed that the 'autossh ...' part
works perfectly when I just execute it in a terminal. When I reboot the
system though, nothing happens.

Even if I restart cron with rcctl, nothing happens. I even confirmed
that sshd is started before cron in rc, I have tried everything I could
come up with, I just have no clue what I'm missing.

Since I am new to OpenBSD, I would appreciate your advice or any clues
on what I have done wrong. Regarding system setup, this is a completely
bare system, I have just run 'sysupgrade -s' and installed autossh.

Thank you in advance!