(solved) Re: rc.local nightmare
On 10/30/23 08:25, Michael van Elst wrote: ea1...@gmail.com (Ramiro Aceves) writes: My script says on the console "Network connectivity to $TARGET is OK." several times before the script dies. So ping works fine. (I have set INTERVAL=3 seconds just to speed things up during testing. Your script shouldn't create output from a background process. When booting, output is piped through a logging process, and when that exits, the next output will abort your process. Thanks so much Michael for the tips. It is working now redirecting stdout and stderr. Now that it is working and I know the reason of what was happening, it is time to learn how to make a simple NetBSD service. nohup doesn't help, it only redirects terminal output. Ideally you should not print anything directly in a background process but write a log file (or use logger / syslog). To avoid any accidential problem, you should also redirect all three standard handles (e.g. to /dev/null). N.B. the connectivity check is a bit sensitive. I suggest to probe with more than 1 packet and to also set a deadline (-w) which allows for one extra second, e.g. ping -n -c 3 -w 4. Thanks for that tip! Ramiro
(solved) Re: rc.local nightmare
On 10/30/23 07:50, RVP wrote: On Sun, 29 Oct 2023, Ramiro Aceves wrote: if [ -x /root/nettest ]; then /root/nettest & fi Many thanks RVP for the superb explanation. It works fine now. If I had had to guess it myself, I think I would never have discovered it. Many thanks! Ramiro. Redirect the output of your script somewhere and then it shoould be OK: ``` if [ -x /root/nettest ]; then /root/nettest >/root/nettest.log 2>&1 & fi ``` (Or, use logger(1) on all output within the script.) What's happening here can be understood if you look at the 2nd last line of /etc/rc which is: ``` rc_real_work "$@" 2>&1 | rc_postprocess ``` The rc_real_work() function runs all the rc scripts in /etc/rc.d/ including /etc/rc.local (via /etc/rc.d/local), and _all_ output is, as you can see, piped to rc_postprocess() When all the scripts finish, /etc/rc exits, and so does the RHS of that pipeline ie. whatever's running rc_postprocess(). So, anything started by rc_real_work() will get a SIGPIPE as soon as it tries to write stuff to its stdout/stderr. The nohup command also didn't work for the same reason. The nohup man-page says: If the standard output is a terminal, the standard output is appended to the file nohup.out in the current directory. If standard error is a terminal, it is directed to the same place as the standard output. Well, here the output of _all_ the scripts is a pipe, so nohup doesn't redirect the output of your command into a nohup.out file and here too it gets a SIGPIPE. HTH, -RVP
Re: ssh and libsqlite.so
I found a way to achieve what I wanted :) There is an option MKMAKEMANDB in mk.conf that does exactly what I want: $ ldd `which apropos whatis` /usr/bin/apropos: -lc.12 => /usr/lib/libc.so.12 /usr/bin/whatis: -lc.12 => /usr/lib/libc.so.12 $ file /usr/share/man/whatis.db /usr/share/man/whatis.db: ASCII text, with very long lines (6084) It also requires to change _mandb to whatdb in /etc/man.conf On Wed, Oct 25, 2023 at 7:49 PM Vitaly Shevtsov wrote: > > Makes sense, Abhinav. Thanks for the clarification. > > On Wed, Oct 25, 2023 at 6:13 PM Abhinav Upadhyay > wrote: > > > > On Wed, Oct 25, 2023 at 6:25 PM Vitaly Shevtsov > > wrote: > > > > > > Hello! > > > > > > No, I'm not saying to remove sqlite from the base image completely. Of > > > course not, since some binaris depend on it. > > > My point is that Full Text Search for apropos and whatis was > > > implemented for NetBSD by using sqlite in 2012 as GSOC. So I think now > > > it's no longer needed for apropos/whatis since the modern mandoc > > > > The semantic search of mandoc's apropos(1) is not the same as "full > > text search" of NetBSD's apropos(1). > > > > The mandoc apropos implementation works on expressions, where you can > > specify a specific mdoc macro and its value. The search will produce > > results containing man pages which satisfy that expression. > > > > On the other hand, NetBSD apropos will work like a typical search engine. > > > > I've never understood the usefulness of doing markup based search, it > > expects the user to have an intimate knowledge of the mdoc macros to > > effectively use it. But I might be biased. > > > > > supports semantic search using POSIX API only. > > > > We could implement full text search using POSIX APIs as well, but if > > Sqlite gives it out of the box, it is extra maintenance work. > > > > - > > Abhinav
Flavors of DOOM?
I have many (40) flavors of DOOM. What are you playing? I am using 'doomlegacy'. I would like anything by Nimrod. (I want more stuff by Nimrod) I have 5 flavors of DOOM by TNT. Any feedback would be nice; thanks
Re: rc.local nightmare
ea1...@gmail.com (Ramiro Aceves) writes: >My script says on the console "Network connectivity to $TARGET is OK." >several times before the script dies. So ping works fine. (I have set >INTERVAL=3 seconds just to speed things up during testing. Your script shouldn't create output from a background process. When booting, output is piped through a logging process, and when that exits, the next output will abort your process. nohup doesn't help, it only redirects terminal output. Ideally you should not print anything directly in a background process but write a log file (or use logger / syslog). To avoid any accidential problem, you should also redirect all three standard handles (e.g. to /dev/null). N.B. the connectivity check is a bit sensitive. I suggest to probe with more than 1 packet and to also set a deadline (-w) which allows for one extra second, e.g. ping -n -c 3 -w 4.
Re: rc.local nightmare
On Sun, 29 Oct 2023, Ramiro Aceves wrote: if [ -x /root/nettest ]; then /root/nettest & fi Redirect the output of your script somewhere and then it shoould be OK: ``` if [ -x /root/nettest ]; then /root/nettest >/root/nettest.log 2>&1 & fi ``` (Or, use logger(1) on all output within the script.) What's happening here can be understood if you look at the 2nd last line of /etc/rc which is: ``` rc_real_work "$@" 2>&1 | rc_postprocess ``` The rc_real_work() function runs all the rc scripts in /etc/rc.d/ including /etc/rc.local (via /etc/rc.d/local), and _all_ output is, as you can see, piped to rc_postprocess() When all the scripts finish, /etc/rc exits, and so does the RHS of that pipeline ie. whatever's running rc_postprocess(). So, anything started by rc_real_work() will get a SIGPIPE as soon as it tries to write stuff to its stdout/stderr. The nohup command also didn't work for the same reason. The nohup man-page says: If the standard output is a terminal, the standard output is appended to the file nohup.out in the current directory. If standard error is a terminal, it is directed to the same place as the standard output. Well, here the output of _all_ the scripts is a pipe, so nohup doesn't redirect the output of your command into a nohup.out file and here too it gets a SIGPIPE. HTH, -RVP
