Re: session mgmt: does POSIX indeed prohibit NOOP execution?
## Peter (pe...@citylink.dinoex.sub.org): > When a program is invoked via /usr/sbin/daemon, it should already be > session leader AND group leader, and then the above code WOULD be a > NOOP, unless POSIX would require the setpgid() to fail and thereby the > program to abort - which, btw, is NOT a NOOP :( https://pubs.opengroup.org/onlinepubs/9699919799/ "The setpgid() function shall fail if: [...] The process indicated by the pid argument is a session leader." Not much room to argue? Regards, Christoph -- Spare Space ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS and power management
On 1/5/2020 16:10, Peter wrote:
> On Wed, 18 Dec 2019 17:22:16 +0100, Karl Denninger
> wrote:
>
>> I'm curious if anyone has come up with a way to do this...
>>
>> I have a system here that has two pools -- one comprised of SSD disks
>> that are the "most commonly used" things including user home directories
>> and mailboxes, and another that is comprised of very large things that
>> are far less-commonly used (e.g. video data files, media, build
>> environments for various devices, etc.)
>
> I'm using such a configuration for more than 10 years already, and
> didn't perceive the problems You describe.
> Disks are powered down with gstopd or other means, and they stay
> powered down until filesystems in the pool are actively accessed.
> A difficulty for me was that postgres autovacuum must be completeley
> disabled if there are tablespaces on the quiesced pools. Another thing
> that comes to mind is smartctl in daemon mode (but I never used that).
> There are probably a whole bunch more of potential culprits, so I
> suggest You work thru all the housekeeping stuff (daemons, cronjobs,
> etc.) to find it.
I found a number of things and managed to kill them off in terms of
active access, and now it is behaving. I'm using "camcontrol idle -t
240 da{xxx}", which interestingly enough appears NOT to survive a
reboot, but otherwise does what's expected.
--
Karl Denninger
k...@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ZFS and power management
On Wed, 18 Dec 2019 17:22:16 +0100, Karl Denninger wrote: I'm curious if anyone has come up with a way to do this... I have a system here that has two pools -- one comprised of SSD disks that are the "most commonly used" things including user home directories and mailboxes, and another that is comprised of very large things that are far less-commonly used (e.g. video data files, media, build environments for various devices, etc.) I'm using such a configuration for more than 10 years already, and didn't perceive the problems You describe. Disks are powered down with gstopd or other means, and they stay powered down until filesystems in the pool are actively accessed. A difficulty for me was that postgres autovacuum must be completeley disabled if there are tablespaces on the quiesced pools. Another thing that comes to mind is smartctl in daemon mode (but I never used that). There are probably a whole bunch more of potential culprits, so I suggest You work thru all the housekeeping stuff (daemons, cronjobs, etc.) to find it. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
session mgmt: does POSIX indeed prohibit NOOP execution?
pgrp = getpid(); if(setpgid(0, pgrp) < 0) err(1, "setpgid"); This appears to me a program trying to deemonize itself (in the old style when there was only job control but no session management). In the case this program is already properly daemonized, e.g. by starting it from /usr/sbin/daemon, this code now fails, invoking the err() clause and thereby aborting. From what I could find out, POSIX does not allow a session leader to do setpgid() on itself. When a program is invoked via /usr/sbin/daemon, it should already be session leader AND group leader, and then the above code WOULD be a NOOP, unless POSIX would require the setpgid() to fail and thereby the program to abort - which, btw, is NOT a NOOP :( So, where is the mistake here? Option 1: I have completely misunderstood something. Then please tell me what. Option 2: The quoted code is bogus. Then why is it in base? option 3: The setpgid() behaviour is bogus. It may stop a session leader from executing it, but it should detect a NOOP and just go thru with it. Then why don't we fix that? Option 4: POSIX is bogus. Unlikely, because as far as I could find out, that part of it was written following the Berkeley implementation. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: usb QR reader
> On 5 Jan 2020, at 17:08, Hans Petter Selasky wrote: > > On 2020-01-05 15:32, Daniel Braniss wrote: >> status 0x6a1a3 >> >> 16:25:17.790304 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 >> frame[0] WRITE 8 bytes >> 21 22 03 00 00 00 00 00 -- -- -- -- -- -- -- -- |!"..| >> flags 0x10 >> status 0x4a1a3 >> >> 16:25:17.790346 usbus5.2 >> DONE-CTRL-EP=,SPD=FULL,NFR=0,SLEN=0,IVAL=50,ERR=TIMEOUT >> flags 0 <0> >> status 0x8a1a5 >> >> 16:25:18.797312 usbus5.2 >> DONE-CTRL-EP=,SPD=FULL,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT >> flags 0x10 > > Hi, > > There are some USB requests your USB device doesn't respond to. ERR=TIMEOUT > > You might find the corresponding driver and enable .debug=16 under : > > sysctl hw.usb | grep debug > > To get more information what exactly goes wrong. > > —HPS did that: sysctl hw.usb.debug=16 but can’t see any changes, /var/log/messages seems the same as before, BTW, the device works fine when I connect it to a mac, so it must be something in the umodem0 cheers, danny ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: usb QR reader
> On 3 Jan 2020, at 13:05, Hans Petter Selasky wrote: > > On 2020-01-03 11:56, Daniel Braniss wrote: >> Hi Hans, >> can you shed some light/help? >> thanks, >> danny >>> On 2 Jan 2020, at 11:11, Daniel Braniss wrote: >>> >>> Hi, >>> after connecting this QR reader I see a new /dev/ttyU but as soon as I try >>> tip, >>> the device disconnects. (BTW, it’s configured as a ‘Virtual Serial Port’) >>> >>> dmsg: >>> … >>> Jan 2 10:54:57 pampero kernel: umodem0 on uhub1 >>> Jan 2 10:54:57 pampero kernel: umodem0: >> 2/0, rev 1.10/1.00, addr 38> on usbus0 >>> Jan 2 10:54:57 pampero kernel: umodem0: data interface 1, has no CM over >>> data, has no break >>> Jan 2 10:56:01 pampero kernel: umodem0: at uhub1, port 2, addr 38 >>> (disconnected) >>> Jan 2 10:56:02 pampero kernel: umodem0: >>> Jan 2 10:56:02 pampero kernel: detached >>> Jan 2 10:56:03 pampero kernel: umodem0 on uhub1 >>> Jan 2 10:56:03 pampero kernel: umodem0: >> 2/0, rev 1.10/1.00, addr 38> on usbus0 >>> Jan 2 10:56:03 pampero kernel: umodem0: data interface 1, has no CM over >>> data, has no break >>> … >>> >>> and usbconfig: >>> pampero# usbconfig >>> ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER >>> (5.0Gbps) pwr=SAVE (0mA) >>> ugen0.2: at usbus0, cfg=0 md=HOST spd=HIGH >>> (480Mbps) pwr=SAVE (500mA) >>> ugen0.4: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) >>> pwr=ON (98mA) >>> ugen0.5: at usbus0, cfg=0 >>> md=HOST spd=FULL (12Mbps) pwr=ON (100mA) >>> ugen0.6: at usbus0, cfg=0 md=HOST spd=SUPER >>> (5.0Gbps) pwr=SAVE (0mA) >>> ugen0.3: at usbus0, >>> cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) >>> ugen0.7: at usbus0, cfg=0 md=HOST spd=FULL >>> (12Mbps) pwr=ON (100mA) <— this is the QR >>> >>> any ideas? > > Can you run: > > usbdump -i usbus0 -f 7 -s 65536 -vvv > > Before attaching the device. Make sure numbers after ugen are 0 and 7. Look > for non ERR=0 . > > —HPS so I connected the QR reader to another host, running 12.1 stable. neo-black-2# usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA) ugen5.2: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) and so i did neo-black-2# usbdump -i usbus5 -f2 -s 65536 -vvv nothing happens, so this is what I get after typing ’tip usb’ and nothing else - i don’t know who is doing the chitchat and after a very short while it disconnects. 16:25:16.753606 usbus5.2 SUBM-INTR-EP=0082,SPD=FULL,NFR=1,SLEN=0,IVAL=5 frame[0] READ 64 bytes flags 0x8a status 0xeb023 16:25:16.753645 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 21 22 01 00 00 00 00 00 -- -- -- -- -- -- -- -- |!"..| flags 0x10 status 0xea1a3 16:25:16.755271 usbus5.2 DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0 frame[0] WRITE 8 bytes flags 0x10 status 0xca1a1 16:25:16.808281 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=50 frame[0] WRITE 8 bytes 02 01 00 00 81 00 00 00 -- -- -- -- -- -- -- -- || flags 0 <0> status 0x6a1a3 16:25:17.790304 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 21 22 03 00 00 00 00 00 -- -- -- -- -- -- -- -- |!"..| flags 0x10 status 0x4a1a3 16:25:17.790346 usbus5.2 DONE-CTRL-EP=,SPD=FULL,NFR=0,SLEN=0,IVAL=50,ERR=TIMEOUT flags 0 <0> status 0x8a1a5 16:25:18.797312 usbus5.2 DONE-CTRL-EP=,SPD=FULL,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT flags 0x10 status 0xaa1a5 16:25:18.850220 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=50 frame[0] WRITE 8 bytes 02 01 00 00 81 00 00 00 -- -- -- -- -- -- -- -- || flags 0 <0> status 0x4a1a3 16:25:18.867314 usbus5.2 DONE-BULK-EP=0081,SPD=FULL,NFR=0,SLEN=0,IVAL=0,ERR=CANCELLED flags 0xa status 0xab00c 16:25:18.867332 usbus5.2 DONE-INTR-EP=0082,SPD=FULL,NFR=0,SLEN=0,IVAL=5,ERR=CANCELLED flags 0x8a status 0x8b01c 16:25:19.854309 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 00 09 00 00 00 00 00 00 -- -- -- -- -- -- -- -- || flags 0x10 status 0x6a1a3 16:25:19.854355 usbus5.2 DONE-CTRL-EP=,SPD=FULL,NFR=0,SLEN=0,IVAL=50,ERR=TIMEOUT flags 0 <0> status 0xaa1a5 16:25:24.793325 usbus5.2 DONE-CTRL-EP=,SPD=FULL,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT flags 0x10 status 0x8a1a5 16:25:25.382614 usbus5.2 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0 frame[0] WRITE 8 bytes 00 05 02 00 00 00 00 00 -- -- -- -- -- -- -- -- || flags 0x50 status 0xea3a3 16:25:25.383872 usbus5.2
Re: FreeBSD SSL libraries and OpenSSL libraries - how to compile own source code
Am 04.01.20 um 22:21 schrieb Mike Karels: FreeBSD 12 uses OpenSSL 1.1.1 in the base (not its own SSL libraries). Thanks Mike, that was the hint to the solution. As a proof of concept, I set up a fresh FreeBSD installation and did NOT install the openssl ports package. Now it's building like a charm. The "best" approach is to convert your code to use OpenSSL 1.1.1, or Yeah the code is already up for 1.1.1 and uses features that have been introduced in version 1.1.1. Thank you very much again. - Alex ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
