OpenBSD vs Docker and Linux: Deploying Ruby on Rails in Production
Hi, Thought I'd share my first Medium article if that's okay: https://medium.com/@brucedandbattered/openbsd-vs-docker-and-linux-deploying-ruby-on-rails-in-production-320c90bcb934 Feedback or criticism would be greatly appreciated! --Bruce
Re: pf state-table-induced instability
On Mon, Aug 28, 2023 at 01:46:32PM +0200, Gabor LENCSE wrote: > Hi Lyndon, > > Sorry for my late reply. Please see my answers inline. > > On 8/24/2023 11:13 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > > Gabor LENCSE writes: > > > > > If you are interested, you can find the results in Tables 18 - 20 of > > > this (open access) paper: https://doi.org/10.1016/j.comcom.2023.08.009 > > Thanks for the pointer -- that's a very interesting paper. > > > > After giving it a quick read through, one thing immediately jumps > > out. The paper mentions (section A.4) a boost in performance after > > increasing the state table size limit. Not having looked at the > > relevant code, so I'm guessing here, but this is a classic indicator > > of a hashing algorithm falling apart when the table gets close to > > full. Could it be that simple? I need to go digging into the pf > > code for a closer look. > > Beware, I wrote it about iptables and not PF! > > As for iptables, it is really so simple. I have done a deeper analysis of > iptables performance as the function of its hash table size. It is > documented in another (open access) paper: > http://doi.org/10.36244/ICJ.2023.1.6 > > However, I am not familiar with the internals of the other two tested > stateful NAT64 implementations, Jool and OpenBSD PF. I have no idea, what > kind of data structures they use for storing the connections. openbsd uses a red-black tree to look up states. packets are parsed into a key that looks up states by address family, ips, ipproto, ports, etc, to find the relevant state. if a state isnt found, it falls through to ruleset evaluation, which is notionally a linked list, but has been optimised. > > You also describe how the performance degrades over time. This > > exactly matches the behaviour we see. Could the fix be as simple > > as cranking 'set limit states' up to, say, two milltion? There is > > one way to find out ... :-) > > As you could see, the highest number of connections was 40M, and the limit > of the states was set to 1000M. It worked well for me then with the PF of > OpenBSD 7.1. > > It would be interesting to find the root cause of the phenomenon, why the > performance of PF seems to deteriorate with time. E.g., somehow the internal > data structures of PF become "polluted" if many connections are established > and then deleted? my first guess is that you're starting to fight agains the pf state purge processing. pf tries to scan the entire state table every 10 seconds (by default) looking for expired states it can remove. this scan process runs every second, but it tries to cover the whole state table by 10 seconds. the more states you have the more time this takes, and this increases linearly with the number of states you have. until relatively recently (post 7.2), the scan and gc processing effectively stopped the world. at work we run with about 2 million states during business hours, and i was seeing the gc processing take up approx 70ms a second, during which packet processing didnt really happen. now the scan can happen without blocking pf packet processing. it still takes cpu time, so there is a point that processing packets and scanning for states will fight each other for time, but at least they're not fighting each other for locks now. > However, I have deleted the content of the state table after each elementary > measurement step using the "pfctl -F states" command. (I am sorry, this > command is missing from the paper, but it is there in my saved "del-pf" > file!) > > Perhaps PF developers could advise us, if the deletion of the states > generate a fresh state table or not. it marks the states as expired, and then the purge scan is able to take them and actually free them. > Could anyone help us in this question? > > Best regards, > > G??bor > > > > > I use binary search to find the highest lossless rate (throughput). > Especially w > > > > > > --lyndon >
Re: Both serial and pc consoles on Super Micro A1SRi-2758F machine
On Mon, Aug 28, 2023 at 04:50:37PM +0200, Otto Moerbeek wrote: > On Mon, Aug 28, 2023 at 10:33:23AM -0400, Christopher Sean Hilton wrote: > > > On Mon, Aug 28, 2023 at 07:41:19AM +0200, Otto Moerbeek wrote: > > > On Sun, Aug 27, 2023 at 08:40:44PM -0400, Christopher Sean Hilton wrote: > > > > > > > [ ...snip... ] > > > > > > I can solve my problems in one of two ways. If I can boot with serial > > > > consoles by setting them up in /etc/boot.conf and also have terminals > > > > on the pc consoles, I'd be happy. I'd also be happy if I could figure > > > > out how to configure the BIOS to make enable the serial port as just > > > > a plain serial port. Super Micro seems to have other ideas and I > > > > understand that this is *my* problem. > > > > > > > > I'll tak any suggestions here. > > > > > > What did you put into /etc/ttys when using a VGA console? > > > > > > -Otto > > > > > > > I've moved it to the serial console config. Admitting in advance that > > I could be mistaken, I've posted the relevant files below. I annotated > > the dmesg output with marks to show where the serial port is detected > > and that the wsdisplay *does not attach* to the detected vga1 > > device. I think that if I could make the wsdisplay device attach then > > my problem would be solved. > > Having wsdisplay(4) without being the under;ying device being marked > as console is atypical. Don't know if it is possible at all. > Here's part of a dmesg for a different OpenBSD machine that I run, also as a packet filter. It has slightly different hardware but in this case, wsdisplay attaches and I get 5 pc terminals as well as a serial console. === dmesg output === acpiprt6 at acpi0: bus 2 (P0P8) acpiprt7 at acpi0: bus 3 (P0P9) acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 *> com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo *> com0: console acpibtn0 at acpi0: PWRB acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 *> pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02 *> inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 *> drm0 at inteldrm0 *> intagp0 at inteldrm0 *> agp0 at intagp0: aperture at 0xd000, size 0x1000 *> inteldrm0: apic 4 int 16, PINEVIEW, gen 3 *> "Intel Pineview Video" rev 0x02 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 21 ... isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0 mux 1 *> vga0 at isa0 port 0x3b0/48 iomem 0xa/131072 *> wsdisplay at vga0 not configured pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0 mux 1 *> vga0 at isa0 port 0x3b0/48 iomem 0xa/131072 *> wsdisplay at vga0 not configured pcppi0 at isa0 port 0x61 ... *> inteldrm0: 1024x768, 32bpp *> wsdisplay0 at inteldrm0 mux 1 pckbd_enable: command error *> wsdisplay0: screen 0-5 added (std, vt100 emulation) In this case wsdisplay is attaching to the intel graphics card built into the chipset. The motherboard here is a much older, much lower performance Intel Atom D525. On the target hardware, when /etc/boot.conf is missing or empty, wsdisplay0 attaches to the vga[01]. As I said in my original post, SuperMicro is doing something *fancy* with the serial port on this motherboard to *enhance* the usefulness of the remote sessions on the serial hardware. Whatever trick that they are pulling is not working correctly. I've scoured the BIOS to find a configuration that make com1: 0x3f8/irq 4, just be a serial UART. I can't find it. I was hoping that either there's a way to configure the kernel to attach vga1 to wsdisplay through `boot -c` or that someone has experience with the BIOS on these machines and has convinced the motherboard to remove the *fancy sauce* attached to the serial ports. Thank you again for your help Otto, -- Chris > > > > Thanks again > > > > -- Chris > > > > Attached output follows: > > > > > > == /etc/boot.conf == > > > > stty com0 115200 > > set tty com0 > > > > > > == /etc/ttys == > > > > # > > # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ > > # > > # name getty typestatus comments > > # > > console "/usr/libexec/getty std.9600" vt220 off secure > > ttyC0 "/usr/libexec/getty std.9600" vt220 on secure > > ttyC1 "/usr/libexec/getty std.9600" vt220 on secure > > ttyC2 "/usr/libexec/getty std.9600" vt220 on secure > > ttyC3 "/usr/libexec/getty std.9600" vt220 on secure > > ttyC4 "/usr/libexec/getty std.9600"
Re: who is smarter?
Dear BSD Community! Shall I apologize? Well, I tried to be strict with you, but you were in control, and you will always part of stay in control. I apologize for my strictness to OpenBSD, but I didn't do anything to the others than being a potential competition. I see, this will still stay complicated. all the best, James Bond On Wed, 23 Aug 2023, 07:18 Berthold Jaksch, wrote: > Dear BSD Community! > > I am just developing root-os based on your system. I know you hate me, > even though I am not sure why. How can we rule that out? > > Probably we cannot but we will quarrel and fight against each other. > > Shall the more intelligent one win. > > all the best, > J.B. > > __ > http://jaksch.eu/2023-08-20 root-os welcome message > >
Re: Both serial and pc consoles on Super Micro A1SRi-2758F machine
On Mon, Aug 28, 2023 at 10:33:23AM -0400, Christopher Sean Hilton wrote: > On Mon, Aug 28, 2023 at 07:41:19AM +0200, Otto Moerbeek wrote: > > On Sun, Aug 27, 2023 at 08:40:44PM -0400, Christopher Sean Hilton wrote: > > > > [ ...snip... ] > > > > I can solve my problems in one of two ways. If I can boot with serial > > > consoles by setting them up in /etc/boot.conf and also have terminals > > > on the pc consoles, I'd be happy. I'd also be happy if I could figure > > > out how to configure the BIOS to make enable the serial port as just > > > a plain serial port. Super Micro seems to have other ideas and I > > > understand that this is *my* problem. > > > > > > I'll tak any suggestions here. > > > > What did you put into /etc/ttys when using a VGA console? > > > > -Otto > > > > I've moved it to the serial console config. Admitting in advance that > I could be mistaken, I've posted the relevant files below. I annotated > the dmesg output with marks to show where the serial port is detected > and that the wsdisplay *does not attach* to the detected vga1 > device. I think that if I could make the wsdisplay device attach then > my problem would be solved. Having wsdisplay(4) without being the under;ying device being marked as console is atypical. Don't know if it is possible at all. > > Thanks again > > -- Chris > > Attached output follows: > > > == /etc/boot.conf == > > stty com0 115200 > set tty com0 > > > == /etc/ttys == > > # > # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ > # > # name getty typestatus comments > # > console "/usr/libexec/getty std.9600" vt220 off secure > ttyC0 "/usr/libexec/getty std.9600" vt220 on secure > ttyC1 "/usr/libexec/getty std.9600" vt220 on secure > ttyC2 "/usr/libexec/getty std.9600" vt220 on secure > ttyC3 "/usr/libexec/getty std.9600" vt220 on secure > ttyC4 "/usr/libexec/getty std.9600" vt220 off secure > ttyC5 "/usr/libexec/getty std.9600" vt220 on secure > ttyC6 "/usr/libexec/getty std.9600" vt220 off secure > ttyC7 "/usr/libexec/getty std.9600" vt220 off secure > ttyC8 "/usr/libexec/getty std.9600" vt220 off secure > ttyC9 "/usr/libexec/getty std.9600" vt220 off secure > ttyCa "/usr/libexec/getty std.9600" vt220 off secure > ttyCb "/usr/libexec/getty std.9600" vt220 off secure > tty00 "/usr/libexec/getty std.115200" unknown on secure might need to play with "local" and/or "softcar" (I always forget which does what) when using a vga console to get a login prompt on tty00 See ttys(5). -Otto > tty01 "/usr/libexec/getty std.115200" unknown on secure > tty02 "/usr/libexec/getty std.9600" unknown off > tty03 "/usr/libexec/getty std.9600" unknown off > tty04 "/usr/libexec/getty std.9600" unknown off > tty05 "/usr/libexec/getty std.9600" unknown off > tty06 "/usr/libexec/getty std.9600" unknown off > tty07 "/usr/libexec/getty std.9600" unknown off > ... > > > == dmesg.boot == > > OpenBSD 7.3 (GENERIC.MP) #3: Tue Jul 25 08:20:26 MDT 2023 > > r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8541495296 (8145MB) > avail mem = 8263225344 (7880MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (50 entries) > bios0: vendor American Megatrends Inc. version "2.1" date 01/18/2018 > bios0: Supermicro A1SRi-2758F > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT UEFI APIC BDAT HPET > SSDT SPCR HEST BERT ERST EINJ > acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.37 MHz, 06-4d-08 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64, > cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 100MHz > cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.66 MHz, 06-4d-08 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64, > cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB > 64b/line
Re: Both serial and pc consoles on Super Micro A1SRi-2758F machine
On Mon, Aug 28, 2023 at 07:41:19AM +0200, Otto Moerbeek wrote: > On Sun, Aug 27, 2023 at 08:40:44PM -0400, Christopher Sean Hilton wrote: > [ ...snip... ] > > I can solve my problems in one of two ways. If I can boot with serial > > consoles by setting them up in /etc/boot.conf and also have terminals > > on the pc consoles, I'd be happy. I'd also be happy if I could figure > > out how to configure the BIOS to make enable the serial port as just > > a plain serial port. Super Micro seems to have other ideas and I > > understand that this is *my* problem. > > > > I'll tak any suggestions here. > > What did you put into /etc/ttys when using a VGA console? > > -Otto > I've moved it to the serial console config. Admitting in advance that I could be mistaken, I've posted the relevant files below. I annotated the dmesg output with marks to show where the serial port is detected and that the wsdisplay *does not attach* to the detected vga1 device. I think that if I could make the wsdisplay device attach then my problem would be solved. Thanks again -- Chris Attached output follows: == /etc/boot.conf == stty com0 115200 set tty com0 == /etc/ttys == # # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ # # name getty typestatus comments # console "/usr/libexec/getty std.9600" vt220 off secure ttyC0 "/usr/libexec/getty std.9600" vt220 on secure ttyC1 "/usr/libexec/getty std.9600" vt220 on secure ttyC2 "/usr/libexec/getty std.9600" vt220 on secure ttyC3 "/usr/libexec/getty std.9600" vt220 on secure ttyC4 "/usr/libexec/getty std.9600" vt220 off secure ttyC5 "/usr/libexec/getty std.9600" vt220 on secure ttyC6 "/usr/libexec/getty std.9600" vt220 off secure ttyC7 "/usr/libexec/getty std.9600" vt220 off secure ttyC8 "/usr/libexec/getty std.9600" vt220 off secure ttyC9 "/usr/libexec/getty std.9600" vt220 off secure ttyCa "/usr/libexec/getty std.9600" vt220 off secure ttyCb "/usr/libexec/getty std.9600" vt220 off secure tty00 "/usr/libexec/getty std.115200" unknown on secure tty01 "/usr/libexec/getty std.115200" unknown on secure tty02 "/usr/libexec/getty std.9600" unknown off tty03 "/usr/libexec/getty std.9600" unknown off tty04 "/usr/libexec/getty std.9600" unknown off tty05 "/usr/libexec/getty std.9600" unknown off tty06 "/usr/libexec/getty std.9600" unknown off tty07 "/usr/libexec/getty std.9600" unknown off ... == dmesg.boot == OpenBSD 7.3 (GENERIC.MP) #3: Tue Jul 25 08:20:26 MDT 2023 r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8541495296 (8145MB) avail mem = 8263225344 (7880MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7f4d8000 (50 entries) bios0: vendor American Megatrends Inc. version "2.1" date 01/18/2018 bios0: Supermicro A1SRi-2758F acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP FPDT FIDT SPMI MCFG WDAT UEFI APIC BDAT HPET SSDT SPCR HEST BERT ERST EINJ acpi0: wakeup devices PEX1(S0) PEX2(S0) PEX3(S0) PEX4(S0) EHC1(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.37 MHz, 06-4d-08 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64, cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2400.66 MHz, 06-4d-08 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64, cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ... cpu7 at mainbus0: apid 14 (application processor) cpu7: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz, 2402.94 MHz, 06-4d-08 cpu7: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64, cpu7: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 16-way L2 cache cpu7: smt 0, core 7, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpiprt0 at
Re: login.conf doesn't seem to be passing the enviroment variable to rc.d
On Mon, Aug 28, 2023 at 11:31:41AM -, Stuart Henderson wrote: > > #!/bin/ksh daemon="/usr/local/sbin/dynaruby" name="dynaruby" . > > "name" is not something which is used by rc.d > > > Then, I set dynaruby_flags and pkg_scripts in /etc/rc.conf.local like this: > > dynaruby_flags="" dynaruby_enable=yes pkg_scripts=dynaruby "dynaruby_enable" is also not something which is used by rc.d. And you don't need to set dynaruby_flags if you're using the default flags. -- Antoine
Re: pf state-table-induced instability
Hi Lyndon, Sorry for my late reply. Please see my answers inline. On 8/24/2023 11:13 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: Gabor LENCSE writes: If you are interested, you can find the results in Tables 18 - 20 of this (open access) paper: https://doi.org/10.1016/j.comcom.2023.08.009 Thanks for the pointer -- that's a very interesting paper. After giving it a quick read through, one thing immediately jumps out. The paper mentions (section A.4) a boost in performance after increasing the state table size limit. Not having looked at the relevant code, so I'm guessing here, but this is a classic indicator of a hashing algorithm falling apart when the table gets close to full. Could it be that simple? I need to go digging into the pf code for a closer look. Beware, I wrote it about iptables and not PF! As for iptables, it is really so simple. I have done a deeper analysis of iptables performance as the function of its hash table size. It is documented in another (open access) paper: http://doi.org/10.36244/ICJ.2023.1.6 However, I am not familiar with the internals of the other two tested stateful NAT64 implementations, Jool and OpenBSD PF. I have no idea, what kind of data structures they use for storing the connections. You also describe how the performance degrades over time. This exactly matches the behaviour we see. Could the fix be as simple as cranking 'set limit states' up to, say, two milltion? There is one way to find out ... :-) As you could see, the highest number of connections was 40M, and the limit of the states was set to 1000M. It worked well for me then with the PF of OpenBSD 7.1. It would be interesting to find the root cause of the phenomenon, why the performance of PF seems to deteriorate with time. E.g., somehow the internal data structures of PF become "polluted" if many connections are established and then deleted? However, I have deleted the content of the state table after each elementary measurement step using the "pfctl -F states" command. (I am sorry, this command is missing from the paper, but it is there in my saved "del-pf" file!) Perhaps PF developers could advise us, if the deletion of the states generate a fresh state table or not. Could anyone help us in this question? Best regards, Gábor I use binary search to find the highest lossless rate (throughput). Especially w --lyndon
Re: login.conf doesn't seem to be passing the enviroment variable to rc.d
On 2023-08-27, Dillon Wreek wrote:
> Hello, I will start from the beginning in hope that someone can make some
> sense of this.
> I have a very simple ruby script that lives in sbin. It sends a get request
> every x minutes to ifconfig to check if the pub ip of the machine changed
> and sends another get request to no-ip to notify any changes.
> the script lives in /usr/local/sbin/ and the script that I wrote under
> rc.d/ looks like this:
>
> /etc/rc.d/dynaruby
> ```
> #!/bin/ksh daemon="/usr/local/sbin/dynaruby" name="dynaruby" .
"name" is not something which is used by rc.d
> /etc/rc.d/rc.subr rc_start() { echo "Starting $name with key:
> $DYNARUBY_KEY" >> /var/log/dynaruby.log /usr/local/sbin/dynaruby } rc_cmd
> $1 ```
Here you are overriding rc_start with a command which does not set the
login class.
You should probably just remove the rc_start section and use the defaults.
Make sure that pexp is set correctly to match the command name (as seen
in ps) for the daemon process.
> Following the man page of rc.d and login.conf, I created an entry like this
> under /etc/login.conf.d/dynaruby:
> dynaruby:setenv=DYNARUBY_KEY=BupCxeBEflVyNK05ypuz25bXuoRc9Rg61qKnOBohyH0=,Xwsirr99KDqkz3Ncytn2AA==:tc=default:
Like I said when you asked on reddit - this is incorrect syntax, you
need to escape the , which is part of DYNARUBY_KEY.
I don't think the escaping is actually documented (at least I didn't find
it), but in setenv you need to use \, if you want a literal comma (otherwise
it is a separator between variable names).
> Then, I set dynaruby_flags and pkg_scripts in /etc/rc.conf.local like this:
> dynaruby_flags="" dynaruby_enable=yes pkg_scripts=dynaruby
> This is everything right? Shouldn't it just work? However when I do "rcctl
> start dynaruby" I just get "dynaruby(failed)" (failed because the ruby
> script can't find the env variable and it exits with 1).
> In /var/log/dynaruby.log, "$DYNARUBY_KEY" is empty, the variable is not
> being passed.
> I tried having the same entry just in login.conf but with the same results.
> I also did the db, did "cap_mkdb", then wiped the whole laptop with a fresh
> install and did the configuration you see above. Still the same results.
you only need cap_mkdb if you've already run cap_mkdb. I would recommend
removing login.conf.db and forget about cap_mkdb.
> I will pay someone to take 15 minutes of their time to walk through this
> with me in a call while watching the terminal together. I'm really
> desperate and I've been hung up on this for over a month.
> I'm seriously considering just ditching rc.d and have a "launcher" ksh
> script that just exports the env variable to the ruby script, then having
> it called by cron on startup and reboot.
nobody's forcing you to use rc.d.
you could start it via cron, alternatively you can just run it from rc.local.
but it certainly should be possible to do this via rc.d.
--
Please keep replies on the mailing list.
Re: File transfer using ftp from bsd.rd booted system
On Aug 27 22:56:59, ch...@mailfence.com wrote: > I would like be able to transfer files over ethernet from a system > that has been booted from bsd.rd Why do you need that? (The only case where I want to have files from a bsd.rd boot is a dmesg of a machine I am looking at, without installing. Which I save on the media I booted from.)
