Re: Script doesn't stop opensearch
On 2024/01/04 19:44:01 +, Mik J wrote: > [...] > I still have a question Omar, you wrote that the pexp content would be matched > "the daemon is found by looking for a process matching that pexp and killing > it." > > Here I have > pexp="$(/usr/local/bin/javaPathHelper -c opensearch) > .*org.opensearch.bootstrap.OpenSearch.*" the $(...) part is evaluated and its output then substituted, so the pexp effectively is /usr/local/jdk-11/bin/java .*org.opensearch.bootstrap.Opensearch.* You can double-check by just copy-pasting pexp="$(...) ..." in a shell and then dumping the value of pexp, for e.g.: echo $pexp Just like you've found, you may get a slightly different java path depending on what you've set JAVA_HOME to. (maybe javaPathHelper could strip extra / at the end; it would have prevented this issue.) Cheers, Omar Polo
Re: Script doesn't stop opensearch
Hello Mike, Omar, Stuart, Thank you for your answers, I've learnt a lot through these. It seems that my problem was due to the fact that I added this variable in my /root/.profile export JAVA_HOME=/usr/local/jdk-11/ # cat /var/run/rc.d/opensearch was then showing a double slash pexp=/usr/local/jdk-11//bin/java .*org.opensearch.bootstrap.OpenSearch.* By removing the ending slash in the root .profile, the double slash disapeared and I have been able to use /etc/rc.d/opensearch stop since then. And also with the check parameter which didn't work at the time. I still have a question Omar, you wrote that the pexp content would be matched "the daemon is found by looking for a process matching that pexp and killing it." Here I have pexp="$(/usr/local/bin/javaPathHelper -c opensearch) .*org.opensearch.bootstrap.OpenSearch.*" But in the ps command javaPathHelper doesn't appear so it can't match it # COLUMNS=1600 ps ax -o command | grep Dopensearch /usr/local/jdk-11/bin/java -Xshare:auto -Dopensearch.networkaddress.cache.ttl=60 -Dopensearch.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dio.netty.allocator.numDirectArenas=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.locale.providers=SPI,COMPAT -Xms6g -Xmx6g -XX:+UseG1GC -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30 -Djava.io.tmpdir=/tmp/opensearch-18321662122565322049 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=data -XX:ErrorFile=/var/log/opensearch/hs_err_pid%p.log -Xlog:gc*,gc+age=trace,safepoint:file=/var/log/opensearch/gc.log:utctime,pid,tags:filecount=32,filesize=64m -Djava.util.concurrent.ForkJoinPool.common.threadFactory=org.opensearch.secure_sm.SecuredForkJoinWorkerThreadFactory -XX:MaxDirectMemorySize=3221225472 -Dopensearch.path.home=/usr/local/opensearch -Dopensearch.path.conf=/etc/opensearch -Dopensearch.distribution.type=tar -Dopensearch.bundled_jdk=true -cp /usr/local/opensearch/lib/*:/usr/local/share/java//classes//jna.jar:/usr/local/share/java//classes//jna-platform.jar org.opensearch.bootstrap.OpenSearch -d -p /var/run/opensearch/opensearch.pid Thank you Le jeudi 4 janvier 2024 à 14:36:05 UTC+1, Stuart Henderson a écrit : On 2024-01-03, Mik J wrote: > Hello, > > I don't understand how the startup/stop script works It uses the string from pexp (as it was when the daemon was _started_; changes to the rc script after startup are ignored) with pgrep(1) -xf to identify the running process (and pkill -xf to actually signal it). > I can confirm that the pid I see in /var/run/opensearch/opensearch.pid is the > same I see in ps ax | grep opensearch > > However when I want to stop the process > # /etc/rc.d/opensearch stop > Nothing happens Show the contents of /var/run/rc.d/opensearch and the output of some pgrep command that identifies the process (e.g. pgrep -lf opensearch). > And I don't understand how this stop command would do something like that > # kill -15 `cat /var/run/opensearch/opensearch.pid` rc.d doesn't use pid files. If the daemon exited without cleaning the file (e.g in a crash) the pid may have been re-used by another process. -- Please keep replies on the mailing list.
Re: Script doesn't stop opensearch
On 2024-01-03, Mik J wrote: > Hello, > > I don't understand how the startup/stop script works It uses the string from pexp (as it was when the daemon was _started_; changes to the rc script after startup are ignored) with pgrep(1) -xf to identify the running process (and pkill -xf to actually signal it). > I can confirm that the pid I see in /var/run/opensearch/opensearch.pid is the > same I see in ps ax | grep opensearch > > However when I want to stop the process > # /etc/rc.d/opensearch stop > Nothing happens Show the contents of /var/run/rc.d/opensearch and the output of some pgrep command that identifies the process (e.g. pgrep -lf opensearch). > And I don't understand how this stop command would do something like that > # kill -15 `cat /var/run/opensearch/opensearch.pid` rc.d doesn't use pid files. If the daemon exited without cleaning the file (e.g in a crash) the pid may have been re-used by another process. -- Please keep replies on the mailing list.
Re: Script doesn't stop opensearch
On 2024-01-04, Mike Fischer wrote: > >> Am 04.01.2024 um 00:06 schrieb Mik J : >> >> However when I want to stop the process >> # /etc/rc.d/opensearch stop >> Nothing happens > > try: > # rcctl stop opensearch > > You are not supposed to ever call the /etc/rc.d/* scripts directly. no, that's fine too. -- Please keep replies on the mailing list.
Re: Script doesn't stop opensearch
On 2024/01/03 23:06:57 +, Mik J wrote:
> Hello,
>
> I don't understand how the startup/stop script works
>
> # cat /etc/rc.d/opensearch
> #!/bin/ksh
>
> daemon="/usr/local/opensearch/bin/opensearch"
> daemon_flags="-d -p /var/run/opensearch/opensearch.pid"
> daemon_user="_opensearch"
>
> . /etc/rc.d/rc.subr
>
> pexp="$(/usr/local/bin/javaPathHelper -c opensearch)
> .*org.opensearch.bootstrap.OpenSearch.*"
this is the "magic" that powers rcctl check and stop. The pidfile is
not used by the rc infrastructure (at least for opensearch), the daemon
is found by looking for a process matching that pexp and killing it.
You can check /etc/rc.d/rc.subr to see what exactly happens.
> rc_reload=NO
>
> rc_pre() {
> install -d -o _opensearch /var/run/opensearch/
> }
>
> rc_cmd $1
>
>
> I can confirm that the pid I see in /var/run/opensearch/opensearch.pid is the
> same I see in ps ax | grep opensearch
>
> However when I want to stop the process
> # /etc/rc.d/opensearch stop
> Nothing happens
What do you mean with 'Nothing happens'? Here it prints
'opensearch(ok)' and then the daemon is stopped. (I generally use
rcctl, but the output and behaviour is the same.)
Re: Script doesn't stop opensearch
> Am 04.01.2024 um 00:06 schrieb Mik J : > > However when I want to stop the process > # /etc/rc.d/opensearch stop > Nothing happens try: # rcctl stop opensearch You are not supposed to ever call the /etc/rc.d/* scripts directly. HTH Mike
Script doesn't stop opensearch
Hello,
I don't understand how the startup/stop script works
# cat /etc/rc.d/opensearch
#!/bin/ksh
daemon="/usr/local/opensearch/bin/opensearch"
daemon_flags="-d -p /var/run/opensearch/opensearch.pid"
daemon_user="_opensearch"
. /etc/rc.d/rc.subr
pexp="$(/usr/local/bin/javaPathHelper -c opensearch)
.*org.opensearch.bootstrap.OpenSearch.*"
rc_reload=NO
rc_pre() {
install -d -o _opensearch /var/run/opensearch/
}
rc_cmd $1
I can confirm that the pid I see in /var/run/opensearch/opensearch.pid is the
same I see in ps ax | grep opensearch
However when I want to stop the process
# /etc/rc.d/opensearch stop
Nothing happens
And I don't understand how this stop command would do something like that
# kill -15 `cat /var/run/opensearch/opensearch.pid`
Thank you
Re: self-hosted man.openbsd.org script?
Hello,
A very good explanation. All crystal clear now, i thank you for your time.
I had a strange idea in the late night about replacing something with
something else, but i see it is not the case and there is no need to
elaborate.
Thank you.
On Thu, Dec 28, 2023 at 3:46 AM Ingo Schwarze wrote:
>
> Hi Mihai,
>
> Mihai Popescu wrote on Thu, Dec 28, 2023 at 01:32:34AM +0200:
>
> > [ removed elaborate instruction about going html from almost txt with
> > man pages ]
> >
> > All this to jump in html boat? Or I got it wrong?
> > Are old man pages deprecated?
>
> Manual pages are not restricted to a specific output format.
>
> THE traditional output format, as far as such a thing exists, is
> black markings on dead trees. That output format later evolved into
> PostScript format and still later into PDF format. Let's call all
> these output modes "typeset output".
>
> Another very old output format is video terminal (CRT) output.
> That's still used a lot, though mostly via virtual terminals nowadays
> rather than on CRTs. But all that is clearly younger than typeset
> output mode.
>
> It has already been explained why nowdays (meaning: during the
> last three decades) it has become convenient to also be able to
> access information remotely via the WWW. The simplest format to
> facilitate that has always been HTML.
>
> Even more recently (as in: during the last decade) source code
> management platforms have become popular that require documentation
> in Markdown format. So that's just another output mode for manual
> pages, see for example
>
> https://github.com/Tairokiya/rfind
> (even though using manual page format isn't widespread on that
>particular platform yet, and this example is of poor quality
>in several respects)
>
> or
>
> https://codeberg.org/fobser/gelatod
> (even though the software used by Codeberg, Forgejo, is currently
>haunted by a bug that prevents correct rendering of the
>standard-conforming Markdown (specifically, CommonMark) code
>generated from manual pages, as you can see - but that bug is
>already fixed and will be gone from the next Forgejo release)
>
>
> So, if the output format is *not* what defines manual pages, then is it
> that defines them?
>
> 1. The idea of having one self-contained document ("manual page")
> for each interface (specifically, CLI command in sections 1 and 8,
> system call in section 2, API function in section 3, kernel driver
> in section 4, configuration file in section 5, domain specific
> language in section 7, kernel function in section 9)
>
> 2. Each of these documents being complete but concise, i.e. not
> mixing in explanations of required prior knowledge about the
> foundations the interface is built on, nor containing tutorial-
> style instructions
>
> 3. A common structure consisting of
> - a one-line description (name section)
> - an informal (i.e. non-BNF), human readable syntax display
>(synopsis section)
> - a description of the arguments and behaviour (description section)
> - various standardized auxiliary sections like "return values",
>"environment", "files", "exit status", "errors", "see also",
>"standards" and so on, to help quickly locate information
>that often needs to be looked up
>
> 4. Universal tygographic conventions helping readability of the
> page for anyone familiar with other manual pages, no matter
> who wrote the particular page currently being looked at
>
> Using HTML output format for reading manual pages allows taking full
> advantage of these concepts just like any other output format does.
> So there is really no need to bash HTML as a manual page output
> format. Also remeber that HTML output format may be particularly
> convenient for people having specific accessibility requirements,
> for example blind people.
>
>
> Maybe what you had in mind is that some software authors abuse HTML as
> an *input* format for documentation, that they write documentation for
> their software directly in HTML format (instead of writing manual pages,
> which can then trivially be convented to HTML if desired, and additionally
> to many other formats). *Maintaining* documentation in HTML format is
> indeed a very bad idea. That usually results in documentation that is
> disorganized, sprawling rather than concise, hinders locating information,
> is riddled with idiosyncratic formatting choices, and next to impossible
> to convert to any other format.
>
> Yours,
> Ingo
Re: self-hosted man.openbsd.org script?
Hi Mihai,
Mihai Popescu wrote on Thu, Dec 28, 2023 at 01:32:34AM +0200:
> [ removed elaborate instruction about going html from almost txt with
> man pages ]
>
> All this to jump in html boat? Or I got it wrong?
> Are old man pages deprecated?
Manual pages are not restricted to a specific output format.
THE traditional output format, as far as such a thing exists, is
black markings on dead trees. That output format later evolved into
PostScript format and still later into PDF format. Let's call all
these output modes "typeset output".
Another very old output format is video terminal (CRT) output.
That's still used a lot, though mostly via virtual terminals nowadays
rather than on CRTs. But all that is clearly younger than typeset
output mode.
It has already been explained why nowdays (meaning: during the
last three decades) it has become convenient to also be able to
access information remotely via the WWW. The simplest format to
facilitate that has always been HTML.
Even more recently (as in: during the last decade) source code
management platforms have become popular that require documentation
in Markdown format. So that's just another output mode for manual
pages, see for example
https://github.com/Tairokiya/rfind
(even though using manual page format isn't widespread on that
particular platform yet, and this example is of poor quality
in several respects)
or
https://codeberg.org/fobser/gelatod
(even though the software used by Codeberg, Forgejo, is currently
haunted by a bug that prevents correct rendering of the
standard-conforming Markdown (specifically, CommonMark) code
generated from manual pages, as you can see - but that bug is
already fixed and will be gone from the next Forgejo release)
So, if the output format is *not* what defines manual pages, then is it
that defines them?
1. The idea of having one self-contained document ("manual page")
for each interface (specifically, CLI command in sections 1 and 8,
system call in section 2, API function in section 3, kernel driver
in section 4, configuration file in section 5, domain specific
language in section 7, kernel function in section 9)
2. Each of these documents being complete but concise, i.e. not
mixing in explanations of required prior knowledge about the
foundations the interface is built on, nor containing tutorial-
style instructions
3. A common structure consisting of
- a one-line description (name section)
- an informal (i.e. non-BNF), human readable syntax display
(synopsis section)
- a description of the arguments and behaviour (description section)
- various standardized auxiliary sections like "return values",
"environment", "files", "exit status", "errors", "see also",
"standards" and so on, to help quickly locate information
that often needs to be looked up
4. Universal tygographic conventions helping readability of the
page for anyone familiar with other manual pages, no matter
who wrote the particular page currently being looked at
Using HTML output format for reading manual pages allows taking full
advantage of these concepts just like any other output format does.
So there is really no need to bash HTML as a manual page output
format. Also remeber that HTML output format may be particularly
convenient for people having specific accessibility requirements,
for example blind people.
Maybe what you had in mind is that some software authors abuse HTML as
an *input* format for documentation, that they write documentation for
their software directly in HTML format (instead of writing manual pages,
which can then trivially be convented to HTML if desired, and additionally
to many other formats). *Maintaining* documentation in HTML format is
indeed a very bad idea. That usually results in documentation that is
disorganized, sprawling rather than concise, hinders locating information,
is riddled with idiosyncratic formatting choices, and next to impossible
to convert to any other format.
Yours,
Ingo
Re: self-hosted man.openbsd.org script?
Mihai Popescu writes: [ removed elaborate instruction about going html from almost txt with man pages ] All this to jump in html boat? Or I got it wrong? Are old man pages deprecated? It can be convenient to have Web-based access to the man pages for systems or software that one isn't currently using (or that isn't already installed). Gentoo is my daily driver, and as it turns out, the OpenBSD man pages are available as a package in the GURU repo, so i have that package installed to allow me to read those man pages on my Gentoo box: $ man cat will get me the man page for GNU coreutils 'cat', but: $ man 1bsd cat will get me the man page for OpenBSD's 'cat'. In the absence of such packaging, a Web-based UI for reading the man pages of other systems can be really helpful (e.g. for checking what functionality is and isn't implemented in a given system's implementation of a particular program, for portability reasons). Alexis.
Re: self-hosted man.openbsd.org script?
[ removed elaborate instruction about going html from almost txt with man pages ] All this to jump in html boat? Or I got it wrong? Are old man pages deprecated?
Re: self-hosted man.openbsd.org script?
Hi Paul,
Paul Pace wrote on Sun, Dec 24, 2023 at 05:25:55AM -0800:
> I have this vague memory of reading someone who posted a script, IIRC,
> to convert the system's man pages to HTML, or similar, into somewhere
> under /var/www and the pages worked just like the highly useful
> man.openbsd.org, and not like the plain text pages that everyone always
> posts to their websites.
>
> Does someone happen to know where that is?
I don't know about any such "script" and believe using a script for it
would be a bad idea - a dirty hack at best.
Converting a whole tree of manual pages to a different format
sounds like the job for the tradition catman(8) utility program
that Christoph Robitschko first implemented in 1993. NetBSD
and FreeBSD contain implementations by various other authors.
OpenBSD does not contain the catman(8) utility because it is rarely
needed by ordinary users and we tend to only include code in the base
system that is useful for many people.
However, the portable mandoc distribution does contain a version
that i wrote together with Michael Stapelberg (of the Debian project)
in 2017:
https://mandoc.bsd.lv/
https://mandoc.bsd.lv/man/catman.8.html
For your purpose, you may want to replace to line
options.fragment = 1;
in mandocd.c by something like
{ char style[] = "/usr/share/misc/mandoc.css";
options.style = style; }
before compiling such that you get complete HTML code including
, , , and elements.
Be careful to not clobber the system mandoc(1) installation by blindly
running "make install". Instead, just manually installing the
binary "mandocd" anywhere in the $PATH is enough. Installing
the "catman" binary in not necessary but won't hurt either.
Also note that viewing the results with a monster browser like
firefox or chrome may require some tweaking with respect to unveil(2),
see the respective files below /usr/local/share/doc/pkg-readmes/.
I freely admit all this is not particularly user-friendly but more
geared towards the needs of server admins. For example, the
server manpages.debian.org is essentially using something similar
to this method. For them, it's critical that this implementation
of catman(8) is much more efficient than the NetBSD and FreeBSD
implementations: it saves lots of time because it does *not* fork
and exec a new parser/formatter process for every manual page
but instead merely reinitialized and resuses the same parser and
formatter process over and over again, which is *much* faster.
With the huge amount of manual pages Debian has to format very
often, their server would not be able to keep up without that
optimization.
Yours,
Ingo
Re: self-hosted man.openbsd.org script?
Paul Pace writes: I have this vague memory of reading someone who posted a script, IIRC, to convert the system's man pages to HTML, or similar, into somewhere under /var/www and the pages worked just like the highly useful man.openbsd.org, and not like the plain text pages that everyone always posts to their websites. Does someone happen to know where that is? Not sure if this is what you were specifically thinking of, but there's man.cgi(8): https://mandoc.bsd.lv/man/man.cgi.8.html Alexis.
Re: self-hosted man.openbsd.org script?
On 12/24/23 08:25, Paul Pace wrote: I have this vague memory of reading someone who posted a script, IIRC, to convert the system's man pages to HTML, or similar, into somewhere under /var/www and the pages worked just like the highly useful man.openbsd.org, and not like the plain text pages that everyone always posts to their websites. Does someone happen to know where that is? /usr/src/usr.bin/mandoc is where the source for man.cgi resides. Frequent small updates take place, I believe it would be good to use the -current source code if you wish to play with it. It has very simple dependencies, so should be no issue running -current man.cgi code compiled on a -stable. ... however ... being that UofT might be down for a few days, I have lit up a VPS with cvsweb and man content on them. https://cvsweb.egoslike.us/ https://man.egoslike.us/ And look, my backups and notes don't suck. :) These are not official, but they are run by one of the people who run the official sites. They will go away once the official site is back up and running. Nick. On 12/23/23 11:16 AM, Nick Holland wrote: On 12/19/23 15:38, Nick Holland wrote: Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick. Unfortunately, it seems there's a problem impacting our servers, and everyone is celebrating the holiday. So ... return of man.openbsd.org, cvsweb.openbsd.org and the install and anoncvs mirrors will be delayed. Nick.
Re: self-hosted man.openbsd.org script?
On Sun, Dec 24, 2023 at 05:25:55AM -0800, Paul Pace wrote: > I have this vague memory of reading someone who posted a script, IIRC, to > convert the system's man pages to HTML, or similar, into somewhere under > /var/www and the pages worked just like the highly useful man.openbsd.org, > and not like the plain text pages that everyone always posts to their > websites. > > Does someone happen to know where that is? Not a script, but there are instructions in the lower half of usr.bin/mandoc/Makefile and you can read the man.cgi manual with $ mandoc -a usr.bin/mandoc/man.cgi.8 https://github.com/openbsd/src/blob/master/usr.bin/mandoc/Makefile#L43-L77
Re: self-hosted man.openbsd.org script?
On Sun, Dec 24, 2023 at 05:25:55AM -0800, Paul Pace wrote: > I have this vague memory of reading someone who posted a script, IIRC, to > convert the system's man pages to HTML, or similar, into somewhere under > /var/www and the pages worked just like the highly useful man.openbsd.org, > and not like the plain text pages that everyone always posts to their > websites. > > Does someone happen to know where that is? My guess would be 'mandoc -T html' is the core utility used. -Otto > > On 12/23/23 11:16 AM, Nick Holland wrote: > > On 12/19/23 15:38, Nick Holland wrote: > > > Hello, > > > > > > man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu > > > and obsdacvs.cs.toronto.edu will be unavailable for site > > > maintenance starting Thursday, December 21 about 6:00am ET > > > (UTC-5) and hopefully be back up and running by Saturday, > > > December 23, 6:00am ET. > > > > > > Sorry for any inconvenience. > > > > > > Nick. > > > > > > > Unfortunately, it seems there's a problem impacting our servers, > > and everyone is celebrating the holiday. > > > > So ... return of man.openbsd.org, cvsweb.openbsd.org and > > the install and anoncvs mirrors will be delayed. > > > > Nick. >
self-hosted man.openbsd.org script?
I have this vague memory of reading someone who posted a script, IIRC, to convert the system's man pages to HTML, or similar, into somewhere under /var/www and the pages worked just like the highly useful man.openbsd.org, and not like the plain text pages that everyone always posts to their websites. Does someone happen to know where that is? On 12/23/23 11:16 AM, Nick Holland wrote: On 12/19/23 15:38, Nick Holland wrote: Hello, man.openbsd.org, cvsweb.openbsd.org, openbsd.cs.toronto.edu and obsdacvs.cs.toronto.edu will be unavailable for site maintenance starting Thursday, December 21 about 6:00am ET (UTC-5) and hopefully be back up and running by Saturday, December 23, 6:00am ET. Sorry for any inconvenience. Nick. Unfortunately, it seems there's a problem impacting our servers, and everyone is celebrating the holiday. So ... return of man.openbsd.org, cvsweb.openbsd.org and the install and anoncvs mirrors will be delayed. Nick.
rc script won't stop
Openbsd 7.3
Hello,
I'm trying to make a startup script for an application called netbox.I'm able
to start it but it won't stop
I tried thisrc_stop() {
# if [[ -f /var/run/netbox.pid ]]; then
kill `cat /var/run/netbox.pid`
rm /var/run/netbox.pid
# fi
}
as I have# cat /var/run/netbox.pid
25065
Or evenrc_stop() {
rc_exec "pkill -f /var/www/htdocs/netbox-3.4.8/env/bin/gunicorn"
}
And when I do /etc/rc.d/netbox stop nothing happens as if the rc_stop
statementt was not evaluated
/etc/rc.d/netbox start works
I userc_pre() {
cat </var/run/netbox_start
APPDIR=${_BASEDIR}/netbox
cd ${_BASEDIR}/netbox
. ${_BASEDIR}/env/bin/activate
export
PYTHONPATH=${_BASEDIR}/env/lib/python3.10/site-packages:${APPDIR}${PYTHONPATH:+:${PYTHONPATH}}
exec gunicorn ${daemon_flags}
EOF
chmod u+x /var/run/netbox_start
}
rc_start() {
rc_exec /var/run/netbox_start
}
Thank you
kshcolor - a script for decorating ksh shell programs and terminals
Hiya folks,
As a learning project to teach myself how to use the ksh shell I wrote a
helper script to set ansi colors and decorations that I'm calling
*kshcolor*.
The script is available here for anyone who is intrigued:
https://github.com/tbullock/kshcolor
The project includes a makefile to build the script, this was necessary
since manually typing ANSI escape sequences is annoying so I chose to
generate those rather than fail at typing them.
To install run `make install`
To run the included test run `make test`
The makefile will install the file kshcolor.sh in $(HOME)/bin
The script includes the following functions:
bk # Sets Black
rd # Sets Red
gr # Sets Green
ye # Sets Yellow
bl # Sets Blue
mg # Sets Magenta
cy # Sets Cyan
wh # Sets White
bg_bk # Sets background Black
bg_rd # Sets background Red
bg_gr # Sets background Green
bg_ye # Sets background Yellow
bg_bl # Sets background Blue
bg_mg # Sets background Magenta
bg_cy # Sets background Cyan
bg_wh # Sets background White
bold# Bold
dim # Dim
underline # Underline
blink # Blink (this may not be implemented by your terminal)
invert # Invert
hidden # Hidden
reset_decorations # clear inherited decorations
These functions do not directly make any visible changes to the
terminal, rather that is left to the function:
decorate# applies configured decorations to the first argument
The decorate function looks at the currently configured decorations
(colours and attributes) and applies the necessary ANSI escape sequences
to tell the terminal how it's argument is to be rendered. If the
terminal doesn't support at least the standard 8 ANSI colours this
become a no-op and leaves the variable undecorated.
The result can then be sent to echo or print or wherever your heart
desires them to go (maybe Narnia!?).
Example:
# Apply foreground and background colours separately
rd
bg_ye
text1=$(decorate "this text is red ")
# Change the background colour
bg_mg
text2=$(decorate "but the background changes")
# Display the decorated text
echo "${text1}${text2}"
reset_decorations
This project was largely an educational evening for me in how ksh
scripting works, if people find it useful, cute or want to use it to
splash the rainbow all over their terminal, then please let me know what
you come up with.
Re: Script launcher and a suite of basic scripts for music production?
On 1/18/23 18:35, Luke A. Call wrote: On 2023-01-18 16:51:28+0100, Brian Durant wrote: On 1/18/23 11:46, Abhishek Chakravarti wrote: Brian Durant writes: The only disadvantage that I can see at this point, is that what I am describing would require a number of open terminals on the desktop, which can be confusing to sort through, particularly during a live performance. Although not a direct answer to your question, perhaps tmux(1) might be helpful here? You could have one tmux session window split into several panes. Cycling through the panes is quite simple with PREFIX + o (the default PREFIX being CTRL+b; in my case it's mapped to CTRL+o Thanks for that. I haven't played around with tmux for ages, but you are correct that could potentially help with terminal clutter. Below are a few [] FWIW I have my tmux set up to use Alt+# (alt+1, alt+2...) key combinations to switch among tmux panes more easily under X than using Ctrl+b every time, which might be helpful if efficiency is important. It is also easier for me to put in muscle memory. I can provide details off-list if desired. Thank you for that generous offer. However, before we go there, I think that there is a need to be more specific (to the extent that I can) at this point, regarding my use case scenario. This can be divided between audio (baritone saxophone, bass and singing) and MIDI (a class compliant launchpad type controller and a class compliant MIDI keyboard). midish looks like a very strong contender, but there are two issues that I am unclear about: 1) Can Fluidsynth instruments be changed on the fly when using midish? 2) Can MIDI events be used to trigger sndio and ffmpeg actions on the system? Here I am thinking of the possibility of using my controller pad as an alternative to a script launcher. The audio side is in many ways more clear cut. I need to be able to record saxophone, voice and bass (I am unfortunately limited to two of these at a time with my current hardware.). The input through the sound card would need to be monitored (when live) and be recorded to file for use as loops with basic sound effects (ffmpeg?). Sooo the big question with relevance to tmux, is how many terminal instances do I need for this scenario? I know my instruments, but as stated, I am a new user to OpenBSD, so I am trying to wrap my head around this scenario. I am cautiously optimistic, as (to my understanding) Ableton Live and Launchpads use scripts (hidden behind proprietary mumbo jumbo and GUI) so it should be possible to do this in OpenBSD as well. Any input on how many terminal instances I will need, particularly with reference to audio, but also the MIDI in my scenario will be very much appreciated, as this will help me nail down my need for using tmux, a script editor, or something completely different to test this scenario in action on OpenBSD.
Re: Script launcher and a suite of basic scripts for music production?
On 2023-01-18 16:51:28+0100, Brian Durant wrote: > On 1/18/23 11:46, Abhishek Chakravarti wrote: > > Brian Durant writes: > > > The only disadvantage that I can see at this point, is that what I am > > > describing would require a number of open terminals on the desktop, > > > which can be confusing to sort through, particularly during a live > > > performance. > > > > Although not a direct answer to your question, perhaps tmux(1) might be > > helpful here? You could have one tmux session window split into several > > panes. Cycling through the panes is quite simple with PREFIX + o (the > > default PREFIX being CTRL+b; in my case it's mapped to CTRL+o > > Thanks for that. I haven't played around with tmux for ages, but you are > correct that could potentially help with terminal clutter. Below are a few > [] FWIW I have my tmux set up to use Alt+# (alt+1, alt+2...) key combinations to switch among tmux panes more easily under X than using Ctrl+b every time, which might be helpful if efficiency is important. It is also easier for me to put in muscle memory. I can provide details off-list if desired.
Re: Script launcher and a suite of basic scripts for music production?
On Wed, Jan 18, 2023 at 04:51:28PM +0100, Brian Durant wrote: > Record audio from USB sound card: > $ aucat -o /home/user/Music/set/1 - ?.wav > > Playback audio file: > $ aucat -i /home/user/Music/set/1 - ?.wav You might want to specify the encoding and other parameters rather than rely on the defaults, which might change. Last year I had to fix a problem for a company who were recording VoIP calls on an OpenBSD system with a simple shell script that invoked aucat twice to record the local and remote audio via separate sndio subdevices. (So the resulting file was stereo, with the local audio on the left channel and the remote party on the right channel.) When the VoIP program ended, the audio was trimmed of digital silence, and then compressed with FLAC, (the choice of which was quite lucky, as you will shortly see). The problem is that they were writing to raw, headerless files rather than wav or au, which I understand was done to make it easier to write the digital silence trimming program. At some point last year, in revision 1.178 of aucat.c, the default file encoding was changed from 16-bit to 24-bit. After upgrading to OpenBSD 7.1, their call recording script continued processing the data as 16-bit, but nobody checked that the call recordings were actually audible. As you can imagine, since the incoming data was actually 24-bit, and yet the two streams were being interleaved as if they were two 16-bit channels, the end result was, if I remember rightly, very bad distortion in the left channel, and pure noise in the right channel. They only noticed the problem after about three weeks because the FLAC processes were taking up a lot more CPU than before, (because they were effectively trying to compress noise). I had to study the exact transformations that their home-grown scripts and programs had performed *, write code to reverse that, decompress all of the FLAC files, (preserving the call metadata that was also stored in them), fix the audio, then re-compress them all with FLAC again. All because: 1. The defaults changed. 2. Their scripts assumed that the defaults would not change. * It was more complicated than it sounds, because the trimming of the digital silence had on some occasions caused further mangling of the data, since it was cutting at the wrong point, and not even at sample boundaries. If the audio data has been compressed with a lossy algorithm, it would have been impossible to recover it. Luckily that was not the case.
Re: Script launcher and a suite of basic scripts for music production?
On 1/18/23 11:46, Abhishek Chakravarti wrote: Hello! Brian Durant writes: The only disadvantage that I can see at this point, is that what I am describing would require a number of open terminals on the desktop, which can be confusing to sort through, particularly during a live performance. Although not a direct answer to your question, perhaps tmux(1) might be helpful here? You could have one tmux session window split into several panes. Cycling through the panes is quite simple with PREFIX + o (the default PREFIX being CTRL+b; in my case it's mapped to CTRL+o Thanks for that. I haven't played around with tmux for ages, but you are correct that could potentially help with terminal clutter. Below are a few thoughts about scripts for music. I will avoid flooding the list with all of my ideas but will simply provide a couple of basic ones. Note that I am new to OpenBSD and have little experience with scripting: OpenBSD music scripts Scan midi/ values (from dmesg or...) and route them to midithru/0 similar to manual commands below: (Is there a use case scenario for rerouting midi/1 - ? by use of midithru/1 -?) $ midicat -d -q midi/0 -q midithru/0 $ midicat -d -q midi/1 -q midithru/0 Record audio from USB sound card: $ aucat -o /home/user/Music/set/1 - ?.wav Playback audio file: $ aucat -i /home/user/Music/set/1 - ?.wav To my knowledge, most USB sound cards have at least two inputs (for microphone and guitar / bass as examples). Important that any script is input sensitive and can automatically number files for each input in order for possible playback with effects by using a simple alias created automatically for the purpose, for the session (?) Also important that monitoring is possible during file creation to avoid pauses while performing a set.
Re: Script launcher and a suite of basic scripts for music production?
Hello! Brian Durant writes: > The only disadvantage that I can see at this point, is that what I am > describing would require a number of open terminals on the desktop, > which can be confusing to sort through, particularly during a live > performance. Although not a direct answer to your question, perhaps tmux(1) might be helpful here? You could have one tmux session window split into several panes. Cycling through the panes is quite simple with PREFIX + o (the default PREFIX being CTRL+b; in my case it's mapped to CTRL+o -- Abhishek Chakravarti abhis...@taranjali.org | Kolkata, IN fifthestate.co.in | refpersys.org | taranjali.org
Script launcher and a suite of basic scripts for music production?
Is there a script launcher that can be used for basic scripts to facilitate live (or close to live) music performances with OpenBSD? One of the reasons that I am a proponent of using OpenBSD with music, is the fact that much can be done simply, from the command line. Recording audio from a USB sound card, using ffmpeg to add reverb and basic effects, rerouting MIDI, switching instruments in Fluidsynth (still working on that one), potentially replaying audio files as clips, etc. There are a lot of possibilities that could be facilitated by a script launcher (and a suite of basic scripts) for new music creators trying out OpenBSD, would definitely be an asset. The only disadvantage that I can see at this point, is that what I am describing would require a number of open terminals on the desktop, which can be confusing to sort through, particularly during a live performance. Which is part of the reason that a script launcher would be useful. The advantages are many, first and foremost fitting in with the Unix philosophy of combining existing programs for new purposes, providing an open source alternative to commercial DAWs such as Ableton and Bitwig, while at the same time removing the frustration for some users that the only DAW available on OpenBSD is LMMS, as well as the temptation for some to try to compile Zrythm or another DAW to OpenBSD. Ideas or suggestions?
Separating stdout and stderr in an rc.d script
Hi there.
I'm trying to figure out how to write an rc.d script that
doesn't redirect stderr to stdout and send both to logger.
Suppose I wanted to keep them separate, and perhaps
pipe one (stdout) to a file or another program. How would
I go about doing that? I tried figuring that out from rc.subr
and these lines seem to be where the magic happens:
${_rcexec} "${daemon_logger:+set -o pipefail; } \
${daemon_execdir:+cd ${daemon_execdir} && } \
$@ \
${daemon_logger:+ 2>&1 | logger -isp ${daemon_logger} -t ${_name}}"
But quite frankly I'm having difficulty understanding these
lines and how I would go about having a script that modifies
or overrides that. Will appreciate any help.
Thanks!
System freezes after execution of large script
Hello everyone, we are running 4 * Dell R430 for firewalling, NAT, accounting etc. for a student network (approx. 5.200 users). We use pf and authpf. Server 1 and 2 form a carp-cluster as well as server 2 und 3. All boxes come with identical hardware and software configuration. The only difference is, that cluster A runs 6.7 and cluster B openbsd 7.0. Every user (-> student) on the network has it's own individual login (directly doing ssh to one of the boxes) to open up a connection to the internet. The user database on server 1 und 2 carries approx 2.600 users, the user database on cluster B the other half. The creation and updating of user information is scripted. Most of the time we just need to update authpf.message to show traffic consumption to the students on login: echo "* UPD (183883)" echo "---\n\nWelcome to studNET!\n\nYou have a maximum of 600 GB traffic available per month.\nYou have already used 9.231 GB in the current month (calculated at 2022-08-08 21:02:07) [.] .\n\n---" >/etc/authpf/users/183883/authpf.message || error_handler echo "... authpf-file /etc/authpf/users/183883/authpf.message generated" if [ $USER_ERROR -eq 0 ] then echo "* UPD (183883|dummyuser, dummyuser) ... success" else echo "* UPD (183883| dummyuser, dummyuser) ... failed" fi This chunk of code is repeated maybe 2.000 times, generated twice a day to a script file and run by cron. *Problem* Maybe once a month server 3 or 4 crash - they just freeze. Sometimes a reboot helps but often it additionaly comes along with a corrupt user database (system wont start, user root not found). If this happens we manually have to recover a working master.passwd and apply pwd_mkdb. As the systems freeze there are no helping log entries or something similar. The only thing for sure is, that *when* it happens its always *after* the script ran and until now it never happend on server 1 or 2 (6.7). *Question* As the problem surely seems to be caused by the exectution of the script the question is why this happens? Heaavy IO or some bug with the hard disk driver? Does someone of you have a clue why the system crashes and even the user database gets corrupted in our setup?! Best regards, Martin Miethe
Re: Request: A script that lists all dependencies to any given package for facilitating offline installations
On 17/07-22 14:26, Allan Streib wrote: > On Sun, Jul 17, 2022, at 1:32 PM, ha...@tutanota.de wrote: > > > It would be useful to have a function that lists all dependencies. > > You can do this if you install the ports tree, see man 7 ports and > "print-run-depends" > > Also the sqlports package may help, though I've never used it. > Indeed, `sqlports` is needed. Example output below: % cd /usr/ports/ && make search key=sxiv Port: nsxiv-30 Path: graphics/nsxiv Info: neo simple X Image Viewer Maint: Thim Cederlund Index: graphics x11 L-deps: devel/libinotify graphics/imlib2 graphics/libexif graphics/libwebp B-deps: R-deps: devel/desktop-file-utils x11/gtk+3,-guic Archs: any Best Regards, Thim Cederlund
Re: Request: A script that lists all dependencies to any given package for facilitating offline installations
On Sun, Jul 17, 2022, at 1:32 PM, ha...@tutanota.de wrote: > It would be useful to have a function that lists all dependencies. You can do this if you install the ports tree, see man 7 ports and "print-run-depends" Also the sqlports package may help, though I've never used it.
Re: Request: A script that lists all dependencies to any given package for facilitating offline installations
On 2022-07-17, ha...@tutanota.de wrote: > Please implement it asap. How rude. That is not how things work here. > (it would be very easy, and of huge help) It's not as easy as you seem to think. -- Please keep replies on the mailing list.
Re: Unbound rc script behavior on 7.1
On 2022-05-29, Georg Pfuetzenreuter wrote: > This is a multi-part message in MIME format. > --ixL2X1ILWFWJlrgqgqUkZvxl > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hi, > > I just installed a fresh copy of OpenBSD 7.1 and copied my working > Unbound configuration from a 7.0 install (attached). > Unbound version on the new system is 1.15.0, on the old one it is 1.13.2. > > Upon starting it, I encounter this: > > opaon$ doas rcctl enable unbound > > opaon$ doas rcctl start unbound > > unboundb/etc/rc.d/unbound: kill: 3957: No such process > > (timeout) > > opaon$ doas rcctl start unbound > > unbound(timeout) > > ... > > opaon# unbound-checkconf > > unbound-checkconf: no errors in /var/unbound/etc/unbound.conf > > opaon# rcctl start unbound > unbound/etc/rc.d/unbound: kill: 33461: No such process > (ok) > > opaon# ps aux |grep unbound > _unbound 84446 0.0 2.1 13372 10356 ?? Ic 1:53PM0:00.01 > unbound -c /var/unbound/etc/unbound.conf No idea what's wrong, but FWIW I'm not seeing any such problems here on a few machines, this is expected to work.. What are the contents of /var/run/rc.d/unbound ?
Re: Unbound rc script behavior on 7.1
Did you miss out # unbound-control-setup perhaps?
[PATCH v2 3/3] script(1): fix exit status wording, use 125 for general failure
This is a base-line attempt at separating errors from the child from the
ones from script itself ‒ 125 is the general-purpose code in POSIX
utilities that exec() (with 126 being ENOEXEC and 127 ‒ ENOENT)
---
Please keep me in CC, as I'm not subscribed.
usr.bin/script/script.1 | 6 ++
usr.bin/script/script.c | 6 +++---
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1
index aa8bb2790..2ce483b97 100644
--- a/usr.bin/script/script.1
+++ b/usr.bin/script/script.1
@@ -80,10 +80,8 @@ or control-D
.Pq Ql ^D
will exit most interactive shells).
.Nm
-will exit with the status of 0 unless any of its child
-processes fail, in which case,
-.Nm
-will return 1.
+will exit with the status of the shell,
+or 125 if it couldn't execute it.
.Pp
Certain interactive commands, such as
.Xr vi 1 ,
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index fd2829033..1c2db608d 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -119,7 +119,7 @@ main(int argc, char *argv[])
default:
fprintf(stderr, "usage: %s [-a] [-c command] [file]\n",
__progname);
- exit(1);
+ exit(125);
}
argc -= optind;
argv += optind;
@@ -206,7 +206,7 @@ void
finish(int signo)
{
int save_errno = errno;
- int status, e = 1;
+ int status, e = 125;
pid_t pid;
while ((pid = wait3(, WNOHANG, 0)) > 0) {
@@ -335,7 +335,7 @@ fail(void)
{
(void)kill(0, SIGTERM);
- done(1);
+ done(125);
}
void
--
2.30.2
signature.asc
Description: PGP signature
[PATCH v2 2/3] script(1): simplify shell execution
Use execl in both paths and the same warn() call
---
Please keep me in CC, as I'm not subscribed.
usr.bin/script/script.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index 763975d6a..fd2829033 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -313,10 +313,7 @@ scriptflush(int signo)
void
doshell(char *cmd)
{
- char *shell;
- char *argp[] = {"sh", "-c", NULL, NULL};
-
- shell = getenv("SHELL");
+ const char *shell = cmd ? NULL : getenv("SHELL");
if (shell == NULL)
shell = _PATH_BSHELL;
@@ -324,14 +321,12 @@ doshell(char *cmd)
(void)fclose(fscript);
login_tty(slave);
- if (cmd != NULL) {
- argp[2] = cmd;
- execv(_PATH_BSHELL, argp);
- warn("unable to execute %s", _PATH_BSHELL);
- } else {
+ if (cmd != NULL)
+ execl(shell, "sh", "-c", cmd, (char *)NULL);
+ else
execl(shell, shell, "-i", (char *)NULL);
- warn("%s", shell);
- }
+
+ warn("unable to execute %s", shell);
fail();
}
--
2.30.2
signature.asc
Description: PGP signature
[PATCH v2 1/3] script(1): actually bubble child errors
script.1 says
> script will exit with the status of 0 unless any of its child
> processes fail, in which case, script will return 1.
This is a patent lie: it only exits with 1 if the host or writer
processes fail, not the actual child
Instead, wait for the child in the writer process and bubble its status
up verbatim (for signals ‒ as shell-style 128+sig)
---
Resending this after 2 weeks with minor tweaks and rebased
(now that v1 4/4 was applied).
I'm interested to see at least 1/3 land, and 2/3 is a very simple
clean-up. If there's anything missing here, please let me know.
Please keep me in CC, as I'm not subscribed.
usr.bin/script/script.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index da22623ff..763975d6a 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -251,16 +251,12 @@ dooutput(void)
sigemptyset();
sigaddset(, SIGALRM);
+ sigaddset(, SIGCHLD);
bzero(, sizeof sa);
sigemptyset(_mask);
sa.sa_handler = scriptflush;
(void)sigaction(SIGALRM, , NULL);
- bzero(, sizeof sa);
- sigemptyset(_mask);
- sa.sa_handler = SIG_IGN;
- (void)sigaction(SIGCHLD, , NULL);
-
if (pledge("stdio proc", NULL) == -1)
err(1, "pledge");
@@ -295,7 +291,17 @@ dooutput(void)
outcc += cc;
sigprocmask(SIG_UNBLOCK, , NULL);
}
- done(0);
+
+ int e = 0, err;
+ while ((err = wait()) == -1 && errno == EINTR)
+ ;
+ if (err != -1) {
+ if (WIFEXITED(e))
+ e = WEXITSTATUS(e);
+ else
+ e = 128 + WTERMSIG(e);
+ }
+ done(e);
}
void
--
2.30.2
signature.asc
Description: PGP signature
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Mon, Jan 03, 2022 at 09:33:19PM +0100, ?? wrote: > On Sun, Jan 02, 2022 at 11:52:49PM +, Jason McIntyre wrote: > > On Sun, Jan 02, 2022 at 11:47:04PM +0100, ?? wrote: > > > On Sun, Jan 02, 2022 at 06:56:37PM +, Jason McIntyre wrote: > > > > On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > > > > > @@ -69,8 +69,8 @@ retaining the prior contents. > > > > > .It Fl c Ar command > > > > > Run > > > > > .Ar command > > > > > +.Pq via Nm sh Fl c Ar command > > > > > instead of an interactive shell. > > > > > > > > or i suppose we could say > > > > > > > > Run > > > > .Nm sh Fl c Ar command , > > > > instead of an interactive shell. > > > Agree, this is much better phrasing, cheers. > > > > > > > > -To run a command with arguments, enclose both in quotes. > > > > why do you want to remove this line? the page is short, and it might > > > > help someone. > > > Because the value for -c is a *shell script*, not a command ??? > > > > i don;t follow. you can run: > > > > $ script -c ls > > > > i.e. a command, not a shell script/ > No, "ls" is definitely a shell script. It forks, execps ["ls"], waits, > then exits with WEXITSTATUS() or 128+WTERMSIG(). > In many ways this is not that different than if you'd ran > `script -c exec\ ls`, in which case the shell would just execp ["ls"]. > > > > I didn't think to change it out ??? it's much more confusing to have this > > > include mention of arguments when, well, they aren't: this reads as-if > > > script -c 'echo a || b' > > > ran ["echo", "a", "||", "b"] ??? you can see issue here. > > why would you think this? the text just explains that if you have > > command+args you should quote it. > Which means absolutely nothing, because script -c doesn't take a command > or arguments ??? it takes a shell program as the argument, which either > starts at the next byte, if non-NUL, or is the entire next argument > (XBD 12.1.2.a). > > Maybe I'm too hopeful in assuming the baseline of understanding how > shell tokenisation works in the user? > > > > -To run a command with arguments, enclose both in quotes. > > > +Scripts longer than just the name of a command need to be quoted, > > > +and are subject to re-expansion. > > that's a horrible sentence. i don;t see any improvement. > Sure. Given this and Matthew's post, I've opted to leave both the Ar > name and sentence as-is. > > Scissor-patch below. > committed, thanks. > Also, unrelatedly, does your MUA just completely give up when decoding > UTF-8 and convert each byte to a "?", or? > yes. i do not have any locale stuff set. jmc > -- >8 -- > Subject: [PATCH v3 4/4] script(1): explicitly specify sh -c > > The original wording is weird and doesn't explicitly say that it does > sh -c, which is the fundamental point ??? spell it out directly > --- > usr.bin/script/script.1 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 > index 28783961a..857b387b6 100644 > --- a/usr.bin/script/script.1 > +++ b/usr.bin/script/script.1 > @@ -68,7 +68,7 @@ or > retaining the prior contents. > .It Fl c Ar command > Run > -.Ar command > +.Nm sh Fl c Ar command > instead of an interactive shell. > To run a command with arguments, enclose both in quotes. > .El > -- > 2.30.2 >
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Sun, Jan 02, 2022 at 11:52:49PM +, Jason McIntyre wrote: > On Sun, Jan 02, 2022 at 11:47:04PM +0100, ?? wrote: > > On Sun, Jan 02, 2022 at 06:56:37PM +, Jason McIntyre wrote: > > > On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > > > > @@ -69,8 +69,8 @@ retaining the prior contents. > > > > .It Fl c Ar command > > > > Run > > > > .Ar command > > > > +.Pq via Nm sh Fl c Ar command > > > > instead of an interactive shell. > > > > > > or i suppose we could say > > > > > > Run > > > .Nm sh Fl c Ar command , > > > instead of an interactive shell. > > Agree, this is much better phrasing, cheers. > > > > > > -To run a command with arguments, enclose both in quotes. > > > why do you want to remove this line? the page is short, and it might > > > help someone. > > Because the value for -c is a *shell script*, not a command ??? > > i don;t follow. you can run: > > $ script -c ls > > i.e. a command, not a shell script/ No, "ls" is definitely a shell script. It forks, execps ["ls"], waits, then exits with WEXITSTATUS() or 128+WTERMSIG(). In many ways this is not that different than if you'd ran `script -c exec\ ls`, in which case the shell would just execp ["ls"]. > > I didn't think to change it out ??? it's much more confusing to have this > > include mention of arguments when, well, they aren't: this reads as-if > > script -c 'echo a || b' > > ran ["echo", "a", "||", "b"] ??? you can see issue here. > why would you think this? the text just explains that if you have > command+args you should quote it. Which means absolutely nothing, because script -c doesn't take a command or arguments ‒ it takes a shell program as the argument, which either starts at the next byte, if non-NUL, or is the entire next argument (XBD 12.1.2.a). Maybe I'm too hopeful in assuming the baseline of understanding how shell tokenisation works in the user? > > -To run a command with arguments, enclose both in quotes. > > +Scripts longer than just the name of a command need to be quoted, > > +and are subject to re-expansion. > that's a horrible sentence. i don;t see any improvement. Sure. Given this and Matthew's post, I've opted to leave both the Ar name and sentence as-is. Scissor-patch below. Also, unrelatedly, does your MUA just completely give up when decoding UTF-8 and convert each byte to a "?", or? -- >8 -- Subject: [PATCH v3 4/4] script(1): explicitly specify sh -c The original wording is weird and doesn't explicitly say that it does sh -c, which is the fundamental point ‒ spell it out directly --- usr.bin/script/script.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 index 28783961a..857b387b6 100644 --- a/usr.bin/script/script.1 +++ b/usr.bin/script/script.1 @@ -68,7 +68,7 @@ or retaining the prior contents. .It Fl c Ar command Run -.Ar command +.Nm sh Fl c Ar command instead of an interactive shell. To run a command with arguments, enclose both in quotes. .El -- 2.30.2 signature.asc Description: PGP signature
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Sun, Jan 02, 2022 at 11:47:04PM +0100, ?? wrote: > On Sun, Jan 02, 2022 at 06:56:37PM +, Jason McIntyre wrote: > > On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > > > @@ -69,8 +69,8 @@ retaining the prior contents. > > > .It Fl c Ar command > > > Run > > > .Ar command > > > +.Pq via Nm sh Fl c Ar command > > > instead of an interactive shell. > > > > or i suppose we could say > > > > Run > > .Nm sh Fl c Ar command , > > instead of an interactive shell. > Agree, this is much better phrasing, cheers. > > > > -To run a command with arguments, enclose both in quotes. > > why do you want to remove this line? the page is short, and it might > > help someone. > Because the value for -c is a *shell script*, not a command ??? i don;t follow. you can run: $ script -c ls i.e. a command, not a shell script/ > I didn't think to change it out ??? it's much more confusing to have this > include mention of arguments when, well, they aren't: this reads as-if > script -c 'echo a || b' > ran ["echo", "a", "||", "b"] ??? you can see issue here. > why would you think this? the text just explains that if you have command+args you should quote it. > This is in contrast to, e.g., FreeBSD script(1), which has a > script outfile argv0 argv1 argvn... > usage. > ugh > -To run a command with arguments, enclose both in quotes. > +Scripts longer than just the name of a command need to be quoted, > +and are subject to re-expansion. that's a horrible sentence. i don;t see any improvement. jmc > I've applied your phrasing to the first hunk, re-phrased the quoting > requirement, and re-named the Ar name from "command" to "script". > This does introduce a minor ambiguity in that script is heavily loaded > here, but "shell program", while more correct, is not the usual > parlance; dunno ??? please see scissor-patch below. > > P.S.: I forgot to note this in the original patchset, > but please keep me in CC, as I'm not subscribed. > > -- >8 -- > Subject: [PATCH v2 4/4] script(1): explicitly specify sh -c, > rename argument name > > The original wording is weird and doesn't explicitly say that it does > sh -c, which is the fundamental point ??? spell it out directly, > and clear up the quoting requirement: -c takes a shell program, > not a command > --- > usr.bin/script/script.1 | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 > index 28783961a..18802504c 100644 > --- a/usr.bin/script/script.1 > +++ b/usr.bin/script/script.1 > @@ -39,7 +39,7 @@ > .Sh SYNOPSIS > .Nm script > .Op Fl a > -.Op Fl c Ar command > +.Op Fl c Ar script > .Op Ar file > .Sh DESCRIPTION > .Nm > @@ -66,11 +66,12 @@ Append the output to > or > .Pa typescript , > retaining the prior contents. > -.It Fl c Ar command > +.It Fl c Ar script > Run > -.Ar command > +.Nm sh Fl c Ar script > instead of an interactive shell. > -To run a command with arguments, enclose both in quotes. > +Scripts longer than just the name of a command need to be quoted, > +and are subject to re-expansion. > .El > .Pp > The script ends when the forked program exits (an > -- > 2.30.2
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Sun, Jan 02, 2022 at 06:56:37PM +, Jason McIntyre wrote: > On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > > @@ -69,8 +69,8 @@ retaining the prior contents. > > .It Fl c Ar command > > Run > > .Ar command > > +.Pq via Nm sh Fl c Ar command > > instead of an interactive shell. > > or i suppose we could say > > Run > .Nm sh Fl c Ar command , > instead of an interactive shell. Agree, this is much better phrasing, cheers. > > -To run a command with arguments, enclose both in quotes. > why do you want to remove this line? the page is short, and it might > help someone. Because the value for -c is a *shell script*, not a command ‒ I didn't think to change it out ‒ it's much more confusing to have this include mention of arguments when, well, they aren't: this reads as-if script -c 'echo a || b' ran ["echo", "a", "||", "b"] ‒ you can see issue here. This is in contrast to, e.g., FreeBSD script(1), which has a script outfile argv0 argv1 argvn... usage. I've applied your phrasing to the first hunk, re-phrased the quoting requirement, and re-named the Ar name from "command" to "script". This does introduce a minor ambiguity in that script is heavily loaded here, but "shell program", while more correct, is not the usual parlance; dunno ‒ please see scissor-patch below. P.S.: I forgot to note this in the original patchset, but please keep me in CC, as I'm not subscribed. -- >8 -- Subject: [PATCH v2 4/4] script(1): explicitly specify sh -c, rename argument name The original wording is weird and doesn't explicitly say that it does sh -c, which is the fundamental point ‒ spell it out directly, and clear up the quoting requirement: -c takes a shell program, not a command --- usr.bin/script/script.1 | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 index 28783961a..18802504c 100644 --- a/usr.bin/script/script.1 +++ b/usr.bin/script/script.1 @@ -39,7 +39,7 @@ .Sh SYNOPSIS .Nm script .Op Fl a -.Op Fl c Ar command +.Op Fl c Ar script .Op Ar file .Sh DESCRIPTION .Nm @@ -66,11 +66,12 @@ Append the output to or .Pa typescript , retaining the prior contents. -.It Fl c Ar command +.It Fl c Ar script Run -.Ar command +.Nm sh Fl c Ar script instead of an interactive shell. -To run a command with arguments, enclose both in quotes. +Scripts longer than just the name of a command need to be quoted, +and are subject to re-expansion. .El .Pp The script ends when the forked program exits (an -- 2.30.2 signature.asc Description: PGP signature
Re: [PATCH 4/4] script(1): explicitly specify sh -c
On Sat, Jan 01, 2022 at 11:07:49PM +0100, ?? wrote: > The original wording is weird and doesn't explicitly say that it does > sh -c, which is the fundamental point ??? spell it out directly > --- > usr.bin/script/script.1 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 > index 28783961a..b9a0f0411 100644 > --- a/usr.bin/script/script.1 > +++ b/usr.bin/script/script.1 > @@ -69,8 +69,8 @@ retaining the prior contents. > .It Fl c Ar command > Run > .Ar command > +.Pq via Nm sh Fl c Ar command > instead of an interactive shell. or i suppose we could say Run .Nm sh Fl c Ar command , instead of an interactive shell. > -To run a command with arguments, enclose both in quotes. why do you want to remove this line? the page is short, and it might help someone. jmc > .El > .Pp > The script ends when the forked program exits (an > -- > 2.30.2
[PATCH 1/4] script(1): actually bubble child errors
script.1 says
> script will exit with the status of 0 unless any of its child
> processes fail, in which case, script will return 1.
This is a patent lie: it only exits with 1 if the host or writer
processes fail, not the actual child
Instead, wait for the child in the writer process and bubble its status
up verbatim (for signals ‒ as shell-style 128+sig)
---
usr.bin/script/script.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index da22623ff..763975d6a 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -251,16 +251,12 @@ dooutput(void)
sigemptyset();
sigaddset(, SIGALRM);
+ sigaddset(, SIGCHLD);
bzero(, sizeof sa);
sigemptyset(_mask);
sa.sa_handler = scriptflush;
(void)sigaction(SIGALRM, , NULL);
- bzero(, sizeof sa);
- sigemptyset(_mask);
- sa.sa_handler = SIG_IGN;
- (void)sigaction(SIGCHLD, , NULL);
-
if (pledge("stdio proc", NULL) == -1)
err(1, "pledge");
@@ -295,7 +291,17 @@ dooutput(void)
outcc += cc;
sigprocmask(SIG_UNBLOCK, , NULL);
}
- done(0);
+
+ int e = 0, err;
+ while ((err = wait()) == -1 && errno == EINTR)
+ ;
+ if (err != -1) {
+ if (WIFEXITED(e))
+ e = WEXITSTATUS(e);
+ else
+ e = 128 + WTERMSIG(e);
+ }
+ done(e);
}
void
--
2.30.2
signature.asc
Description: PGP signature
[PATCH 2/4] script(1): simplify shell execution
Use execl in both paths and the same warn() call
---
usr.bin/script/script.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index 763975d6a..fd2829033 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -313,10 +313,7 @@ scriptflush(int signo)
void
doshell(char *cmd)
{
- char *shell;
- char *argp[] = {"sh", "-c", NULL, NULL};
-
- shell = getenv("SHELL");
+ const char *shell = cmd ? NULL : getenv("SHELL");
if (shell == NULL)
shell = _PATH_BSHELL;
@@ -324,14 +321,12 @@ doshell(char *cmd)
(void)fclose(fscript);
login_tty(slave);
- if (cmd != NULL) {
- argp[2] = cmd;
- execv(_PATH_BSHELL, argp);
- warn("unable to execute %s", _PATH_BSHELL);
- } else {
+ if (cmd != NULL)
+ execl(shell, "sh", "-c", cmd, (char *)NULL);
+ else
execl(shell, shell, "-i", (char *)NULL);
- warn("%s", shell);
- }
+
+ warn("unable to execute %s", shell);
fail();
}
--
2.30.2
signature.asc
Description: PGP signature
[PATCH 3/4] script(1): fix exit status wording, use 125 for general failure
This is a base-line attempt at separating errors from the child from the
ones from script itself ‒ 125 is the general-purpose code in POSIX
utilities that exec() (with 126 being ENOEXEC and 127 ‒ ENOENT)
---
usr.bin/script/script.1 | 6 ++
usr.bin/script/script.c | 6 +++---
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1
index 7bc559377..28783961a 100644
--- a/usr.bin/script/script.1
+++ b/usr.bin/script/script.1
@@ -80,10 +80,8 @@ or control-D
.Pq Ql ^D
will exit most interactive shells).
.Nm
-will exit with the status of 0 unless any of its child
-processes fail, in which case,
-.Nm
-will return 1.
+will exit with the status of the shell,
+or 125 if it failed to start it.
.Pp
Certain interactive commands, such as
.Xr vi 1 ,
diff --git a/usr.bin/script/script.c b/usr.bin/script/script.c
index fd2829033..1c2db608d 100644
--- a/usr.bin/script/script.c
+++ b/usr.bin/script/script.c
@@ -119,7 +119,7 @@ main(int argc, char *argv[])
default:
fprintf(stderr, "usage: %s [-a] [-c command] [file]\n",
__progname);
- exit(1);
+ exit(125);
}
argc -= optind;
argv += optind;
@@ -206,7 +206,7 @@ void
finish(int signo)
{
int save_errno = errno;
- int status, e = 1;
+ int status, e = 125;
pid_t pid;
while ((pid = wait3(, WNOHANG, 0)) > 0) {
@@ -335,7 +335,7 @@ fail(void)
{
(void)kill(0, SIGTERM);
- done(1);
+ done(125);
}
void
--
2.30.2
signature.asc
Description: PGP signature
[PATCH 4/4] script(1): explicitly specify sh -c
The original wording is weird and doesn't explicitly say that it does sh -c, which is the fundamental point ‒ spell it out directly --- usr.bin/script/script.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr.bin/script/script.1 b/usr.bin/script/script.1 index 28783961a..b9a0f0411 100644 --- a/usr.bin/script/script.1 +++ b/usr.bin/script/script.1 @@ -69,8 +69,8 @@ retaining the prior contents. .It Fl c Ar command Run .Ar command +.Pq via Nm sh Fl c Ar command instead of an interactive shell. -To run a command with arguments, enclose both in quotes. .El .Pp The script ends when the forked program exits (an -- 2.30.2 signature.asc Description: PGP signature
Re: cron sh script fork
Todd C. Miller wrote:
> On Mon, 15 Nov 2021 20:13:01 +0300, misc@abrakadabra.systems wrote:
>
> > [/opt/bin]$ cat check.sh
> > #!/bin/sh
> >
> > _ret=$(ps aux | grep sleeploop.sh | grep -v grep | awk '{print $2}')
> > test -z ${_ret} && /opt/bin/sleeploop.sh &
>
> By default, ps uses 80 columns so the information is probably being
> cut off. I'm guessing your interactive terminal is wider than 80
> columns. You can add 'w' a few times to your ps options to extend
> the width but you are much better off using pgrep for this.
pgrep is better. But there are so many risks in this construct I would not
trust it at all.
Re: cron sh script fork
On Mon, 15 Nov 2021 20:13:01 +0300, misc@abrakadabra.systems wrote:
> [/opt/bin]$ cat check.sh
> #!/bin/sh
>
> _ret=$(ps aux | grep sleeploop.sh | grep -v grep | awk '{print $2}')
> test -z ${_ret} && /opt/bin/sleeploop.sh &
By default, ps uses 80 columns so the information is probably being
cut off. I'm guessing your interactive terminal is wider than 80
columns. You can add 'w' a few times to your ps options to extend
the width but you are much better off using pgrep for this.
- todd
Re: cron sh script fork
Your "ps" pipeline could identify other processes. If I was on your
machine, I would start a long-running process with sleeploop.sh as an
argument, your script sees it, and misbehaves. Don't do this.
man 5 crontab
A method to do this safer was
-s command
Only a single instance of command will be run concurrently.
Additional instances of command will not be scheduled until the
earlier one completes.
misc@abrakadabra.systems wrote:
> I have one script (sleeploop.sh) running in background and second (check.sh)
> to test if sleeploop is running and if not then start it.
>
>
> [/opt/bin]$ cat sleeploop.sh
> #!/bin/sh
> while true
> do
> sleep 5
> done
>
> [/opt/bin]$ cat check.sh
> #!/bin/sh
>
> _ret=$(ps aux | grep sleeploop.sh | grep -v grep | awk '{print $2}')
> test -z ${_ret} && /opt/bin/sleeploop.sh &
>
>
> When i start check.sh from the shell it works fine; if there is no pid
> check.sh
> starts sleeploop.sh, otherwise it gets the pid and exiting.
> If i put check.sh in cron it spawns another sleeploop.sh process every time
> when triggered.
>
>
> dmesg:
> OpenBSD 7.0 (GENERIC.MP) #1: Fri Oct 29 12:04:07 MDT 2021
>
> r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 1810530304 (1726MB)
> avail mem = 1739616256 (1659MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb6b0 (91 entries)
> bios0: vendor American Megatrends Inc. version "0608" date 08/10/2012
> bios0: ASUSTeK COMPUTER INC. P8H61-M LX3 R2.0
> acpi0 at bios0: ACPI 5.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT
> acpi0: wakeup devices P0P1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
> PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) PEG0(S4)
> PEGP(S4) PEG1(S4) [...]
> 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) Pentium(R) CPU G2020 @ 2.90GHz, 2900.44 MHz, 06-3a-09
> 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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz, 2900.04 MHz, 06-3a-09
> 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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0
> acpimcfg0: addr 0xf800, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (P0P1)
> acpiprt2 at acpi0: bus 2 (RP01)
> acpiprt3 at acpi0: bus -1 (RP02)
> acpiprt4 at acpi0: bus -1 (RP03)
> acpiprt5 at acpi0: bus -1 (RP04)
> acpiprt6 at acpi0: bus -1 (RP05)
> acpiprt7 at acpi0: bus 3 (RP06)
> acpiprt8 at acpi0: bus 1 (PEG0)
> acpiprt9 at acpi0: bus -1 (PEG1)
> acpiprt10 at acpi0: bus -1 (PEG2)
> acpiprt11 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: not present
> acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
> acpicmos0 at acpi0
> acpibtn0 at acpi0: PWRB
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C0B" at acpi0 not configured
> "PNP0C14" at acpi0 not configured
> acpicpu0 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpipwrres0 at acpi0: FN00, resource for FAN0
> acpipwrres1 at acpi0: FN01, resource for FAN1
> acpipwrres2 at acpi0: FN0
cron sh script fork
I have one script (sleeploop.sh) running in background and second (check.sh)
to test if sleeploop is running and if not then start it.
[/opt/bin]$ cat sleeploop.sh
#!/bin/sh
while true
do
sleep 5
done
[/opt/bin]$ cat check.sh
#!/bin/sh
_ret=$(ps aux | grep sleeploop.sh | grep -v grep | awk '{print $2}')
test -z ${_ret} && /opt/bin/sleeploop.sh &
When i start check.sh from the shell it works fine; if there is no pid check.sh
starts sleeploop.sh, otherwise it gets the pid and exiting.
If i put check.sh in cron it spawns another sleeploop.sh process every time
when triggered.
dmesg:
OpenBSD 7.0 (GENERIC.MP) #1: Fri Oct 29 12:04:07 MDT 2021
r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1810530304 (1726MB)
avail mem = 1739616256 (1659MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb6b0 (91 entries)
bios0: vendor American Megatrends Inc. version "0608" date 08/10/2012
bios0: ASUSTeK COMPUTER INC. P8H61-M LX3 R2.0
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT
acpi0: wakeup devices P0P1(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) PEG0(S4)
PEGP(S4) PEG1(S4) [...]
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) Pentium(R) CPU G2020 @ 2.90GHz, 2900.44 MHz, 06-3a-09
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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Pentium(R) CPU G2020 @ 2.90GHz, 2900.04 MHz, 06-3a-09
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,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus 2 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus -1 (RP05)
acpiprt7 at acpi0: bus 3 (RP06)
acpiprt8 at acpi0: bus 1 (PEG0)
acpiprt9 at acpi0: bus -1 (PEG1)
acpiprt10 at acpi0: bus -1 (PEG2)
acpiprt11 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpicpu0 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10), C1(1000@1
mwait.1), PSS
acpicpu1 at acpi0: C3(350@80 mwait.1@0x20), C2(500@59 mwait.1@0x10), C1(1000@1
mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 106 degC
acpitz1 at acpi0: critical temperature is 106 degC
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
cpu0: using VERW MDS workaround (except on vmm entry)
cpu0: Enhanced SpeedStep 2900 MHz: speeds: 2900, 2800, 2700, 2600, 2500, 2400,
2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 3G Host" rev 0x09
ppb0 at pci0 dev 1 function 0 "Intel Core 3G PCIE" rev 0x09: msi
pci1 at ppb0 bus 1
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 2500" rev 0x09
drm0 at inteldrm0
inteldrm0: msi, IVYBRIDGE, gen 7
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 23
usb0 at ehci0: USB revisi
Re: OpenBSD 7.0--cron will not run a certain script
On 11/11/21 4:09 PM, Łukasz Moskała wrote: W dniu 11.11.2021 o 23:55, Jeff Ross pisze: Hi, /bin/sh -x /home/jross/sync_to_odroidn2.sh cat ./sync_to_ordoidn2.sh Looks like you have typo in file name to me :) odroid in first, ordoid in second. Egads. Thank you! That was indeed the problem :-) Jeff
Re: OpenBSD 7.0--cron will not run a certain script
W dniu 11.11.2021 o 23:55, Jeff Ross pisze: Hi all, This is on a Raspberry Pi 3B+ (dmesg to follow). Here's my crontab: jross@pi:/home/jross $ crontab -l SHELL=/bin/sh MAILTO="" # #minute hour mday month wday command */2 * * * * /bin/sh /home/jross/upload_latest.sh 2>&1 * * * * * python3 4Kwebcam_loop_no_scp.py 38 * * * * /bin/sh -x /home/jross/sync_to_odroidn2.sh 2>&1 The first 2 scripts work fine. The last one absolutely will not. Here's the very simple script: jross@pi:/home/jross $ cat ./sync_to_ordoidn2.sh #!/bin/sh logger "starting sync to odroidn2" pgrep -x rsync if [ $? -eq 0 ]; then echo "`date` rsync still running...exiting" >> /var/log/rsync_to_odroidn2.out else echo "`date` starting rsync..." >> /var/log/rsync_to_odroidn2.out /usr/local/bin/rsync -avPz /home/jross/webcam/ odroidn2:/samba/starhouse/webcam/ | tee -a /var/log/rsync_to_odroidn2.out echo "`date` finished rsync..." >> /var/log/rsync_to_odroidn2.out fi Here's where cron says it's firing the script: 2021-11-11 15:38:01.305599500 127.0.0.1: cron.info: Nov 11 15:38:01 cron[95324]: (jross) CMD (/bin/sh -x /home/jross/sync_to_odroidn2.sh 2>&1) But, no comment into syslog from the logger line and the script simply does not run. Running the script manually, though, works fine: 2021-11-11 15:47:05.959176500 127.0.0.1: user.notice: Nov 11 15:47:05 jross: starting sync to odroidn2 sending incremental file list 4Kwebcam_2021/ 4Kwebcam_2021/4Kwebcam_1636669302.jpg 2,113,298 100% 6.85MB/s 0:00:00 (xfr#1, to-chk=75/1323) 4Kwebcam_2021/4Kwebcam_1636669333.jpg 2,109,678 100% 1.48MB/s 0:00:01 (xfr#2, to-chk=74/1323) 4Kwebcam_2021/4Kwebcam_1636669357.jpg 2,108,931 100% 1.73MB/s 0:00:01 (xfr#3, to-chk=73/1323) ...and so on I originally had this script running under cron with */10 in the minute column. As a part of debugging I've adjusted the interval to every 5 minutes and then to a set minute in the hour. I'm using full paths everywhere in the script so it can't be that. I do not know what else to try... Jeff dmesg: jross@pi:/home/jross $ dmesg OpenBSD 7.0 (GENERIC.MP) #1332: Thu Sep 30 16:53:51 MDT 2021 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 970907648 (925MB) avail mem = 908574720 (866MB) random: good seed from bootblocks mainbus0 at root: Raspberry Pi 3 Model B Plus Rev 1.3 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: CRC32,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu2: CRC32,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu3: 512KB 64b/line 16-way L2 cache cpu3: CRC32,ASID16 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20210700 apm0 at mainbus0 simplefb0 at mainbus0: 656x416, 32bpp wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10 bcmintc0 at simplebus0 pluart0 at simplebus0 bcmsdhost0 at simplebus0: 250 MHz base clock sdmmc0 at bcmsdhost0: 4-bit, sd high-speed, mmc high-speed, dma dwctwo0 at simplebus0 bcmdog0 at simplebus0 bcmrng0 at simplebus0 bcmtemp0 at simplebus0 "local_intc" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc1 at sdhc0: 4-bit, sd high-speed, mmc high-speed "firmware" at simplebus0 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 19200 kHz "leds" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured "bootloader" at mainbus0 not configured dt: 445 probes usb0 at dwctwo0: USB revision 2.0 scsibus0 at sdmmc0: 2 targets, initia
OpenBSD 7.0--cron will not run a certain script
Hi all, This is on a Raspberry Pi 3B+ (dmesg to follow). Here's my crontab: jross@pi:/home/jross $ crontab -l SHELL=/bin/sh MAILTO="" # #minute hour mday month wday command */2 * * * * /bin/sh /home/jross/upload_latest.sh 2>&1 * * * * * python3 4Kwebcam_loop_no_scp.py 38 * * * * /bin/sh -x /home/jross/sync_to_odroidn2.sh 2>&1 The first 2 scripts work fine. The last one absolutely will not. Here's the very simple script: jross@pi:/home/jross $ cat ./sync_to_ordoidn2.sh #!/bin/sh logger "starting sync to odroidn2" pgrep -x rsync if [ $? -eq 0 ]; then echo "`date` rsync still running...exiting" >> /var/log/rsync_to_odroidn2.out else echo "`date` starting rsync..." >> /var/log/rsync_to_odroidn2.out /usr/local/bin/rsync -avPz /home/jross/webcam/ odroidn2:/samba/starhouse/webcam/ | tee -a /var/log/rsync_to_odroidn2.out echo "`date` finished rsync..." >> /var/log/rsync_to_odroidn2.out fi Here's where cron says it's firing the script: 2021-11-11 15:38:01.305599500 127.0.0.1: cron.info: Nov 11 15:38:01 cron[95324]: (jross) CMD (/bin/sh -x /home/jross/sync_to_odroidn2.sh 2>&1) But, no comment into syslog from the logger line and the script simply does not run. Running the script manually, though, works fine: 2021-11-11 15:47:05.959176500 127.0.0.1: user.notice: Nov 11 15:47:05 jross: starting sync to odroidn2 sending incremental file list 4Kwebcam_2021/ 4Kwebcam_2021/4Kwebcam_1636669302.jpg 2,113,298 100% 6.85MB/s 0:00:00 (xfr#1, to-chk=75/1323) 4Kwebcam_2021/4Kwebcam_1636669333.jpg 2,109,678 100% 1.48MB/s 0:00:01 (xfr#2, to-chk=74/1323) 4Kwebcam_2021/4Kwebcam_1636669357.jpg 2,108,931 100% 1.73MB/s 0:00:01 (xfr#3, to-chk=73/1323) ...and so on I originally had this script running under cron with */10 in the minute column. As a part of debugging I've adjusted the interval to every 5 minutes and then to a set minute in the hour. I'm using full paths everywhere in the script so it can't be that. I do not know what else to try... Jeff dmesg: jross@pi:/home/jross $ dmesg OpenBSD 7.0 (GENERIC.MP) #1332: Thu Sep 30 16:53:51 MDT 2021 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 970907648 (925MB) avail mem = 908574720 (866MB) random: good seed from bootblocks mainbus0 at root: Raspberry Pi 3 Model B Plus Rev 1.3 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu1: CRC32,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu2: CRC32,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4 cpu3: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu3: 512KB 64b/line 16-way L2 cache cpu3: CRC32,ASID16 efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20210700 apm0 at mainbus0 simplefb0 at mainbus0: 656x416, 32bpp wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10 bcmintc0 at simplebus0 pluart0 at simplebus0 bcmsdhost0 at simplebus0: 250 MHz base clock sdmmc0 at bcmsdhost0: 4-bit, sd high-speed, mmc high-speed, dma dwctwo0 at simplebus0 bcmdog0 at simplebus0 bcmrng0 at simplebus0 bcmtemp0 at simplebus0 "local_intc" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc1 at sdhc0: 4-bit, sd high-speed, mmc high-speed "firmware" at simplebus0 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "clocks" at mainbus0 not configured "phy" at mainbus0 not configured "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: 19200 kHz "leds" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured "bootloader" at mainbus0 not configured dt: 445 probes usb0 at dwctwo0: USB revision 2.0 scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removabl
Re: IPv6: how to trigger script when address prefix changes?
Hi Daniel! I didn’t know about ifstated(8) but reading the man page I get the impression that it only triggers on up/down events. And for other things it relies on polling, e.g. sending a ping packet somewhere every 10 seconds to test reachability. The route monitor command seems somewhat more promising. Though I don’t know if it works event based internally or not. I have tested this as follows: I have a ULA prefix configured on my router. Yes I know, for a small network that is not really required. So my router actually advertises 2 prefixes to my clients: - The one from my provider (/56 changed to /64) - My ULA prefix, also expanded to a /64 prefix. Testing a provider prefix change is impractical because it happens fairly infrequently and I suspect they tear down the whole PPPoE session and have my router reconnect. (That would probably have side effects as outlined in RFC 8978 which would complicate matters.) So I decided to use changes to the ULA prefix to test this in a somewhat controlled way. 1) Start `route monitor` 2) Run `ifconfig em0|grep inet6` to get a baseline 3) Modify my ULA prefix on the router 4) Check the output of the `route monitor` command 5) Run `ifconfig em0|grep inet6` to get differences Results: - Indeed, when the ULA changes, `route monitor` on my host produces output. - The non-temporary IP using the old prefix still existed and was not marked in any way other than having very slightly lower pltime and vltime attributes (5s difference on ≈ 1 and 2 hours). - A new IPv6 address using the new prefix was added to the interface. Note that the IID was completely new, probably caused by the autoconf setting. Also, my test script configured in /etc/hostname.em0 as "!/root/bin/if_log.sh \$if“ does not trigger which confirms my theory that this only runs when /etc/netstart is executed. Which does not happen for prefix changes. The output of `route monitor` itself does not seem to be easily parseable for what I need. But that is secondary. At least I have a potential trigger mechanism. OTOH the route(8) command needs to kept running and I’m not so sure that is a great idea. Maybe polling myself would be easier after all? I repeated the experiment by changing the ULA prefix back to its original value. This again yielded `route monitor` output and the pltime/vltime differences where reversed while keeping all IPs. So provisionally my algorithm could look like this: - Wait for output from `route monitor`… (I would need to figure out, how to generate events from this output stream.) - Then run `ifconfig em0|grep inet6|grep -vE '(temporary|fe80:|deprecated|inet6 fd)‘|grep autoconf` which will yield all candidate IPs I’m interested in. - Figure out the correct one (by comparing the pltime/vltime values if there is more than one IP) - Extract the IPv6 IP from the line - Do my actions (update DNS, pf(4) table, etc.) using the IP. For some actions I might need to keep state in the form of the old IP to remove it. Anyway, thanks for your suggestions. Mike > Am 07.10.2021 um 04:34 schrieb Daniel Jakots : > > On Thu, 7 Oct 2021 02:52:13 +0200, Mike Fischer > wrote: > >> Would a IPv6 address prefix change be something the hotplug(4) / >> hotplugd(8) mechanism would see? > > It would rather be ifstated(8), but I don't think so. I've never looked > into this, but if I were, I would check the route(8) monitor command: > https://man.openbsd.org/route#monitor
Re: IPv6: how to trigger script when address prefix changes?
On Thu, 7 Oct 2021 02:52:13 +0200, Mike Fischer wrote: > Would a IPv6 address prefix change be something the hotplug(4) / > hotplugd(8) mechanism would see? It would rather be ifstated(8), but I don't think so. I've never looked into this, but if I were, I would check the route(8) monitor command: https://man.openbsd.org/route#monitor
IPv6: how to trigger script when address prefix changes?
Hi! I have a need to update DNS records, and potentially pf(4) rules or tables when a public routable IPv6 address of my host changes. Such a change is expected whenever slaacd receives a change in the advertised IPv6 address prefix(es) from the router(s). Other than regularly polling the interface for its IPv6 addresses and comparing to a previously saved state, is there some way to get notified actively when such a change happens? (I am not a friend of polling as it wastes cpu cycles and on average comes with a delay of half the polling interval. slaacd already knows that a change is happening so why not let it tell my script?) Note that I am not concerned about the temporary IPv6 addresses generated by RFC 8981 privacy settings. Just any addresses using a fixed/static Interface Identifier (IID), either manually configured, EUI-64 or randomly generated. In other words this is about incoming traffic from the Internet to services running on my host, not host initiated outgoing traffic. If changes to temporary addresses also trigger my script, I could live with that but I don’t need this information. >From reading the documentation, scripts configured in hostname.if(5) using the >! syntax do not seem to work for this, as they seem to be triggered >only when /etc/netstart is executed? (This is not documented anywhere I could >find.) Would a IPv6 address prefix change be something the hotplug(4) / hotplugd(8) mechanism would see? Can someone enlighten me please? Thanks! Mike
Re: LMTP dovecot timeout when sieve's run script
Dear Stuart, Thank you. Sometime it's to easy. The quick response with answer says it all. Pascal. signature.asc Description: This is a digitally signed message part
Re: LMTP dovecot timeout when sieve's run script
On 2021-08-06, pas...@pascallen.nl wrote: > --=-auHtfLlFC+dDT6m6OqcT > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: 7bit > > Hallo, > > > Dovecot lmtp is timing out when running a script started from sieve. > This happens when emails are to big. Have attachments that are to big. > > How can I change the time out? https://doc.dovecot.org/configuration_manual/sieve/plugins/extprograms/
LMTP dovecot timeout when sieve's run script
Hallo,
Dovecot lmtp is timing out when running a script started from sieve.
This happens when emails are to big. Have attachments that are to big.
How can I change the time out?
Output:
Jul 1 13:28:55 router dovecot: lmtp(pas...@pascallen.nl)<90734>: Error: program
exec:/usr/local/lib/dovecot/sieve/gpgit.pl (93645): Execution timed
out (> 1 msecs)
Jul 1 13:28:56 router dovecot: lmtp(pas...@pascallen.nl)<90734>: Error: program
exec:/usr/local/lib/dovecot/sieve/gpgit.pl (93645): Forcibly
terminated with signal 15
Jul 1 13:28:56 router dovecot: lmtp(pas...@pascallen.nl)<90734>: Panic: output stream (temp iostream in
/tmp/dovecot.lmtp. for (program client seekable output)) is missing
error handling
Jul 1 13:28:56 router dovecot:
lmtp(pas...@pascallen.nl)<90734>: Fatal:
master: service(lmtp): child 90734 killed with signal 6 (core not
dumped - https://dovecot.org/bugreport.html#coredumps - set service
lmtp { drop_priv_before_exec=yes })
--
Met vriendelijke groet,
Pascal Huisman
Penn's aunts made great apple pies at low prices. No one else in
town could compete with the pie rates of Penn's aunts.
signature.asc
Description: This is a digitally signed message part
Re: Git Daemon rc Script Not Stopping
It was merely a hunch. Thinking of it, I believe there is some magic to cope with that. Never mind my likely red herring. /Alexander On January 6, 2021 3:49:46 PM GMT+01:00, ben wrote: >>Without looking too far, check what pgrep gives. My first suspicion is >>the initial space in your 'daemon_flags'. > >Why does daemon_flags not permit spaces? rc.subr(8) has no information on >including or lack of whitespace in daemon_flags.
Re: Git Daemon rc Script Not Stopping
>Without looking too far, check what pgrep gives. My first suspicion is >the initial space in your 'daemon_flags'. Why does daemon_flags not permit spaces? rc.subr(8) has no information on including or lack of whitespace in daemon_flags.
Re: Git Daemon rc Script Not Stopping
On Tue, Jan 05, 2021 at 03:19:29PM -0500, ben wrote: > >The original version of this script installed by the port contains > >rc_reload=NO and also uses a very different pexp. > > I checked out the original rc script, and it works. Why didn't my pexp var > work > for the script? The term should match the process, and yet the daemon was > still > running? Without looking too far, check what pgrep gives. My first suspicion is the initial space in your 'daemon_flags'. Also, what Stefan said. /Alexander
Re: Git Daemon rc Script Not Stopping
On Tue, Jan 05, 2021 at 03:19:29PM -0500, ben wrote: > >The original version of this script installed by the port contains > >rc_reload=NO and also uses a very different pexp. > > I checked out the original rc script, and it works. Why didn't my pexp var > work > for the script? The term should match the process, and yet the daemon was > still > running? > > Because the process is called "git-daemon", not "git", and the rc.d framework passes the -x option to pgrep.
Re: Git Daemon rc Script Not Stopping
>The original version of this script installed by the port contains >rc_reload=NO and also uses a very different pexp. I checked out the original rc script, and it works. Why didn't my pexp var work for the script? The term should match the process, and yet the daemon was still running?
Re: Git Daemon rc Script Not Stopping
On Tue, Jan 05, 2021 at 02:41:51PM -0500, ben wrote: > Hello, Misc; > > I've been playing around with rc.d scripts and I've stumbled upon an issue in > my git daemon script: > > #!/bin/ksh > # > # $OpenBSD: gitdaemon.rc,v 1.4 2019/07/16 09:56:55 stsp Exp $ > > daemon="/usr/local/libexec/git/git-daemon --detach" > daemon_flags=" --detach --export-all --reuseaddr --base-path=/home/git > /home/git" > daemon_user="git" > > . /etc/rc.d/rc.subr > > pexp=git > > rc_cmd $1 The original version of this script installed by the port contains rc_reload=NO and also uses a very different pexp. Why did you see a need to modify this script? Could you not simply set these options in /etc/rc.conf.local and use the unmodified script? gitdaemon_flags=--export-all --reuseaddr --base-path=/home/git /home/git gitdaemon_user=git
Git Daemon rc Script Not Stopping
Hello, Misc; I've been playing around with rc.d scripts and I've stumbled upon an issue in my git daemon script: #!/bin/ksh # # $OpenBSD: gitdaemon.rc,v 1.4 2019/07/16 09:56:55 stsp Exp $ daemon="/usr/local/libexec/git/git-daemon --detach" daemon_flags=" --detach --export-all --reuseaddr --base-path=/home/git /home/git" daemon_user="git" . /etc/rc.d/rc.subr pexp=git rc_cmd $1 Upon running starting the script, the daemon starts, however, upon restarting the script doesn't restart, that is, I don't get two gitdaemon(ok) messages (one for stopping one for starting), and when checking the pid the process has not restarted. Am I missing somthing in my script or is it just an issue with git? Thank you in advance. Ben Raskin
Re: tmux rc script not stopping
In retrospect, command -v seems to be more portable than which[1]. So a better version would be: if command -v tmux >/dev/null 2>&1; then # if not inside a tmux session, and if no session is started, start # a new session test -z "$TMUX" && (tmux attach || tmux new-session) fi Though I suppose this is likely academic in nature. [1]: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then -- https://amissing.link
Re: tmux rc script not stopping
On 20/10/07 02:34PM, ben wrote: > Hello, Misc; > > I'm attempting to write an rc script to start a tmux session: What problem are you trying to solve by using an rc script? I have this in my .kshrc for automatic tmux sessions: if which tmux >/dev/null 2>&1; then # if not inside a tmux session, and if no session is started, start # a new session test -z "$TMUX" && (tmux attach || tmux new-session) fi Of course, in the end the solution depends on what you want to do. -- https://amissing.link
Re: tmux rc script not stopping
>So, if you have edited the script to add a pexp *after* starting >it, you'll need to remove that /var/run file otherwise it will >still use the old one or the default. I've checked the /var/run file for the script name and pexp, and everything was in place; I made sure to first change the pexp variable in the script then run it. What I'm still confused about is why is it that when I overwrote the rc_stop function after sourcing rc.subr I wasn't able to stop the script.
Re: tmux rc script not stopping
On 2020-10-07, ben wrote: >>I think you might need a pexp variable, process grep expression to be used b >>y pgrep to determine if the service is running. > > I've tried using pexp, the result is the same; I can start the script and > receive the 'tmux(ok)' message, but upon running the '/etc/rc.d/tmux stop' > I receive no messages and the script silently exits. > > No messages implies a pexp mismatch. When you start a daemon from an rc.d script the original pexp is saved to /var/run/rc.d/$daemon so that if a package is updated while a daemon is running (which may result in the process title actually changing) it will still be possible to identify if the original daemon is running. So, if you have edited the script to add a pexp *after* starting it, you'll need to remove that /var/run file otherwise it will still use the old one or the default.
Re: tmux rc script not stopping
>I think you might need a pexp variable, process grep expression to be used b >y pgrep to determine if the service is running. I've tried using pexp, the result is the same; I can start the script and receive the 'tmux(ok)' message, but upon running the '/etc/rc.d/tmux stop' I receive no messages and the script silently exits.
Re: tmux rc script not stopping
> On Oct 7, 2020, at 2:35 PM, ben wrote:
>
> Hello, Misc;
>
> I'm attempting to write an rc script to start a tmux session:
>
>#!/bin/sh
>
>daemon="/usr/bin/tmux"
>daemon_flags=" new -d -s MAINTMUX -n SHELL"
>
>. /etc/rc.d/rc.subr
>
>rc_reload=NO
>
>rc_stop() {
>/usr/bin/tmux kill-session -t MAINTMUX
>}
>
>rc_cmd $1
>
> I am able to start it, however upon running the stop command I receive no
> output, and the tmux session I've created with the start command is still
> active.
>
> The man pages for rc.subr(8) state that rc_* functions are to be overwritten
> after sourcing rc.subr, which is what I'm doing.
>
> Am I missing something? Is there anything else I need to set prior to
> starting/stopping the rc script? Thank you in advance.
>
>
> Ben Raskin
>
I think you might need a pexp variable, process grep expression to be used by
pgrep to determine if the service is running.
tmux rc script not stopping
Hello, Misc;
I'm attempting to write an rc script to start a tmux session:
#!/bin/sh
daemon="/usr/bin/tmux"
daemon_flags=" new -d -s MAINTMUX -n SHELL"
. /etc/rc.d/rc.subr
rc_reload=NO
rc_stop() {
/usr/bin/tmux kill-session -t MAINTMUX
}
rc_cmd $1
I am able to start it, however upon running the stop command I receive no
output, and the tmux session I've created with the start command is still
active.
The man pages for rc.subr(8) state that rc_* functions are to be overwritten
after sourcing rc.subr, which is what I'm doing.
Am I missing something? Is there anything else I need to set prior to
starting/stopping the rc script? Thank you in advance.
Ben Raskin
Re: ksh very slow compared to bash when running ghostscript's ./configure script
On Wed, 22 Jul 2020 19:09:41 +0200 Theo Buehler wrote: > On Wed, Jul 22, 2020 at 07:05:31PM +0200, Theo Buehler wrote: > > This works around the bug: > > And this might even be a correct fix: > > diff --git configure.ac configure.ac > index 0d22ad59b..d27222459 100644 > --- configure.ac > +++ configure.ac > @@ -483,7 +483,7 @@ AC_LINK_IFELSE( >[AC_LANG_PROGRAM([#include ], [ >return(0); >])], > - [CFLAGS_SANITIZE="$CFLAGS"], > [CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"]) > + [CFLAGS_SANITIZE="$CFLAGS"], > [CFLAGS_SANITIZE="'ADDRESS_SANITIZER_NOT_SUPPORTED*'"]) > > CFLAGS="$CFLAGS_SAVED" Ah yes, great, that fixes it independently of any improvement to ksh's glob code. Many thanks. I'll try to make this change to ghostpdl's main git repository in the next few days. Thanks, - Jules -- http://op59.net
Re: ksh very slow compared to bash when running ghostscript's ./configure script
On Wed, Jul 22, 2020 at 01:10:38PM -0600, Todd C. Miller wrote: > On Wed, 22 Jul 2020 18:38:42 +0200, Theo Buehler wrote: > > > Likely glob. Many glob implementations were found to suffer from > > complexity issues: https://research.swtch.com/glob > > > > The glob(3) in libc was fixed > > https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b5 > > 9 > > but ksh's builtin glog still has the issue. > > At the very least we should collapse consecutive stars. This is a > separate issue from making gmatch() iterative. Yes. This makes sense and fixes this issue. ok tb > > - todd > > Index: bin/ksh/misc.c > === > RCS file: /cvs/src/bin/ksh/misc.c,v > retrieving revision 1.74 > diff -u -p -u -r1.74 misc.c > --- bin/ksh/misc.c7 Jul 2020 10:33:58 - 1.74 > +++ bin/ksh/misc.c22 Jul 2020 19:08:20 - > @@ -615,6 +615,9 @@ do_gmatch(const unsigned char *s, const > break; > > case '*': > + /* collapse consecutive stars */ > + while (ISMAGIC(p[0]) && p[1] == '*') > + p += 2; > if (p == pe) > return 1; > s--;
Re: ksh very slow compared to bash when running ghostscript's ./configure script
On Wed, 22 Jul 2020 18:38:42 +0200, Theo Buehler wrote: > Likely glob. Many glob implementations were found to suffer from > complexity issues: https://research.swtch.com/glob > > The glob(3) in libc was fixed > https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b5 > 9 > but ksh's builtin glog still has the issue. At the very least we should collapse consecutive stars. This is a separate issue from making gmatch() iterative. - todd Index: bin/ksh/misc.c === RCS file: /cvs/src/bin/ksh/misc.c,v retrieving revision 1.74 diff -u -p -u -r1.74 misc.c --- bin/ksh/misc.c 7 Jul 2020 10:33:58 - 1.74 +++ bin/ksh/misc.c 22 Jul 2020 19:08:20 - @@ -615,6 +615,9 @@ do_gmatch(const unsigned char *s, const break; case '*': + /* collapse consecutive stars */ + while (ISMAGIC(p[0]) && p[1] == '*') + p += 2; if (p == pe) return 1; s--;
Re: ksh very slow compared to bash when running ghostscript's ./configure script
Wow. We really don't live in the best of possible worlds. Theo Buehler wrote: > On Wed, Jul 22, 2020 at 07:05:31PM +0200, Theo Buehler wrote: > > This works around the bug: > > And this might even be a correct fix: > > diff --git configure.ac configure.ac > index 0d22ad59b..d27222459 100644 > --- configure.ac > +++ configure.ac > @@ -483,7 +483,7 @@ AC_LINK_IFELSE( >[AC_LANG_PROGRAM([#include ], [ >return(0); >])], > - [CFLAGS_SANITIZE="$CFLAGS"], > [CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"]) > + [CFLAGS_SANITIZE="$CFLAGS"], > [CFLAGS_SANITIZE="'ADDRESS_SANITIZER_NOT_SUPPORTED*'"]) > > CFLAGS="$CFLAGS_SAVED" > >
Re: ksh very slow compared to bash when running ghostscript's ./configure script
On Wed, Jul 22, 2020 at 07:05:31PM +0200, Theo Buehler wrote: > This works around the bug: And this might even be a correct fix: diff --git configure.ac configure.ac index 0d22ad59b..d27222459 100644 --- configure.ac +++ configure.ac @@ -483,7 +483,7 @@ AC_LINK_IFELSE( [AC_LANG_PROGRAM([#include ], [ return(0); ])], - [CFLAGS_SANITIZE="$CFLAGS"], [CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"]) + [CFLAGS_SANITIZE="$CFLAGS"], [CFLAGS_SANITIZE="'ADDRESS_SANITIZER_NOT_SUPPORTED*'"]) CFLAGS="$CFLAGS_SAVED"
Re: ksh very slow compared to bash when running ghostscript's ./configure script
On Wed, Jul 22, 2020 at 06:38:42PM +0200, Theo Buehler wrote: > > I don't know what's causing this. Is there some algorithm inside ksh > > that could be running into complexity issues somehow? > > Likely glob. Many glob implementations were found to suffer from > complexity issues: https://research.swtch.com/glob > > The glob(3) in libc was fixed > https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b59 > but ksh's builtin glog still has the issue. > > A quick ktrace seems to confirm that (I terminated the shell after it > hung a while): > > 58829 sh 5.883025 RET getdents 1832/0x728 > 58829 sh 40.637429 PSIG SIGTERM caught handler=0x64287f47850 mask=0<> > > This likely points to the readdir call in globit() before globit() recurses: > https://github.com/openbsd/src/blob/master/bin/ksh/eval.c#L1089-L1102 Well: AC_LINK_IFELSE( [AC_LANG_PROGRAM([#include ], [ return(0); ])], [CFLAGS_SANITIZE="$CFLAGS"], [CFLAGS_SANITIZE="ADDRESS_SANITIZER_NOT_SUPPORTED*"]) This works around the bug: diff --git configure.ac configure.ac index 0d22ad59b..f670bde1b 100644 --- configure.ac +++ configure.ac @@ -495,7 +495,7 @@ dnl check for sanitize build warnings support dnl AC_MSG_CHECKING([compiler/linker address santizer build warnings support]) -CFLAGS_SANITIZE_TRY="$CFLAGS_SANITIZE -W -Wall -Wno-unused-parameter -Wno-sign-compare -Wno-implicit-fallthrough -Wno-missing-field-initializers -Wno-shift-negative-value -Wno-old-style-declaration -Wno-unused-but-set-parameter" +CFLAGS_SANITIZE_TRY="'$CFLAGS_SANITIZE' -W -Wall -Wno-unused-parameter -Wno-sign-compare -Wno-implicit-fallthrough -Wno-missing-field-initializers -Wno-shift-negative-value -Wno-old-style-declaration -Wno-unused-but-set-parameter" CFLAGS_SAVED="$CFLAGS" CFLAGS="$CFLAGS_SANITIZE_TRY"
Re: ksh very slow compared to bash when running ghostscript's ./configure script
> I don't know what's causing this. Is there some algorithm inside ksh > that could be running into complexity issues somehow? Likely glob. Many glob implementations were found to suffer from complexity issues: https://research.swtch.com/glob The glob(3) in libc was fixed https://github.com/openbsd/src/commit/5c36dd0c22429e7b00ed5df80ed1383807532b59 but ksh's builtin glog still has the issue. A quick ktrace seems to confirm that (I terminated the shell after it hung a while): 58829 sh 5.883025 RET getdents 1832/0x728 58829 sh 40.637429 PSIG SIGTERM caught handler=0x64287f47850 mask=0<> This likely points to the readdir call in globit() before globit() recurses: https://github.com/openbsd/src/blob/master/bin/ksh/eval.c#L1089-L1102
ksh very slow compared to bash when running ghostscript's ./configure script
It looks like ksh runs much slower than bash with current Ghostscript's ./configure script - for me it takes 20m, compared with 45s under bash. This is on OpenBSD 6.7 GENERIC.MP#1 amd64. [This kernel has visa@'s wait4() patch (see recent 'gdb in uninterruptible wait' thread), but the same problem also occurred last week with the release kernel, GENERIC.MP#182).] To reproduce: git clone https://git.ghostscript.com/ghostpdl.git cd ghostpdl AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 CONFIGURE_STYLE=gnu ./autogen.sh This runs things like autoreconf, then does ./configure. It takes 20m on my machine, seemingly getting stuck for a a long time after outputting 'checking compiler/linker address santizer build warnings support...' and consuming 80% cpu. Modifying autogen.sh to use /usr/local/bin/bash instead of ksh when running ./configure, like this: diff --git a/autogen.sh b/autogen.sh index 7a0783623..2f6624b10 100755 --- a/autogen.sh +++ b/autogen.sh @@ -50,4 +50,4 @@ else echo "running ./configure $@" fi -$srcdir/configure "$@" && echo +/usr/local/bin/bash $srcdir/configure "$@" && echo - results in the above ./autogen.sh command completing in about 45s for me. (this is with a clean tree again.) I don't know what's causing this. Is there some algorithm inside ksh that could be running into complexity issues somehow? [A colleague reports that ksh on Linux doesn't run slowly. But i guess ksh has diverged a lot on OpenBSD/Linux, so that's perhaps not too surprising.] Thanks, - Jules -- http://op59.net
Re: A shell script to create chroot jails
Hi Raf,
Thanks a lot for your help. Now I’ve updated it regarding to your great
advices. Would you mind to take a look again?
https://gist.github.com/siegfried/907904752b1b5db760782f476f44fca4
Sincerely yours,
Siegfried
zhiqiang@gmail.com
> On Apr 20, 2020, at 5:40 AM, Raf Czlonka wrote:
>
> On Sun, Apr 19, 2020 at 08:30:11AM BST, Zhi-Qiang Lei wrote:
>> Hi,
>>
>> I wrote a script to create chroot jails. Please feel free to use and
>> comment. Thanks.
>>
>> https://gist.github.com/siegfried/907904752b1b5db760782f476f44fca4
>>
>
> Hi Zhi-Qiang,
>
> Please test *before* you post!
>
> Where are $JAIL_HOME and $IMAGE_HOME coming from?
>
> You aren't checking for $1 at all.
>
> Why the "example" in mktemp?
>
> Where do the iso files come from?
>
> You use "/bin/sh" but also "function" - bad style IMO.
>
> You aren't checking vnd0 is currently in use or not - please consider
> something like this:
>
> vnd_dev="$(/sbin/vnconfig -l | awk '/not in use/,FS=":" { print $1 ;
> exit }')"
>
> Apart from the MAKEDEV step, you can avoid using cd.
>
> /usr/lib is a built-in system directory so there's no need to pass
> it to ldconfig.
>
> Not an issue here but *not* using '{}' around variable name inside
> a string, will bite you in the arse one day! ;^)
>
> Regards,
>
> Raf
A shell script to create chroot jails
Hi, I wrote a script to create chroot jails. Please feel free to use and comment. Thanks. https://gist.github.com/siegfried/907904752b1b5db760782f476f44fca4 Sincerely yours, Siegfried zhiqiang@gmail.com
simple script to merge faq files in a single html (was Re: Web documentation available offline by default?)
Please find attached a preliminary rough shell script that does the job for the faq[0-9]+.html files, keeping track of anchors appropriately. It is missing pf, ports, and other files, but it's a starting point. Disclaimer: this is unofficial stuff and I am not asking for this script to be supported by OpenBSD or included in the release workflow. I will probably put the script in my git repo, just in case somebody wants to use it. Comments are welcome. HTH faq_local.sh Description: Bourne shell script
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
SIGKILL seems pretty harsh, have you tried SIGTERM instead? On Sun, Feb 9, 2020 at 12:48 PM aisha wrote: > > You need to use pkill -9 to kill rspamd, which i think should be added > to the stop part of the rspamd daemon. > > At least this is what I have been using, any other methods would be nice > to know. > > --- > Aisha > blog.aisha.cc
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On 2020-02-09, aisha wrote: > You need to use pkill -9 to kill rspamd, which i think should be added > to the stop part of the rspamd daemon. > > At least this is what I have been using, any other methods would be nice > to know. Something wedges in rspamd in the version in 6.6 when you signal it to shutdown, I didn't manage to track it down before 6.6 release. It was fixed in newer rspamd so works just fine in -current, but that's too big of an update to backport to 6.6-stable (and really the main practical effect on 6.6 is that your reboots are ~30 seconds slower than they should be).
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On 2020-02-09 11:46, aisha wrote: You need to use pkill -9 to kill rspamd, which i think should be added to the stop part of the rspamd daemon. At least this is what I have been using, any other methods would be nice to know. You dont need to restart rspamd if you're just modifying a config file. You can just run "rcctl reload rspamd" to reload your config files if you've made any changes. The rspamd maintainer has acknowledged the issue, and the restarting issue is fixed in current.
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
You need to use pkill -9 to kill rspamd, which i think should be added to the stop part of the rspamd daemon. At least this is what I have been using, any other methods would be nice to know. --- Aisha blog.aisha.cc On 2020-02-09 14:38, Özgür Kazancci wrote: Hi Stephan, I got the same trouble. Fresh installation of OpenBSD 6.6 and redis+rspamd. Was google-ing regarding that issue and got your workaround. What you mean by "if you enable rspamd etc on boot by rcctl.."? Mine, is already enabled (I issued rcctl enable rspamd after the installation) Thank you, Ozgur. On 29/10/2019 23:44, List wrote: Hi, I am myself running a MX that uses rspamd + postfix. I did have the same issue. Especially when running rspamd and adding redis to the setup. I think what causes the problem is rspamd which uses JITs. These JITS break W^X. If you enable rspamd etc on boot by (rcctl enable ...). And reboot.. Everything works fine. At least for me did. Don't hesitate asking. Kind regards, Stephan
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
Hi Stephan, I got the same trouble. Fresh installation of OpenBSD 6.6 and redis+rspamd. Was google-ing regarding that issue and got your workaround. What you mean by "if you enable rspamd etc on boot by rcctl.."? Mine, is already enabled (I issued rcctl enable rspamd after the installation) Thank you, Ozgur. On 29/10/2019 23:44, List wrote: Hi, I am myself running a MX that uses rspamd + postfix. I did have the same issue. Especially when running rspamd and adding redis to the setup. I think what causes the problem is rspamd which uses JITs. These JITS break W^X. If you enable rspamd etc on boot by (rcctl enable ...). And reboot.. Everything works fine. At least for me did. Don't hesitate asking. Kind regards, Stephan
Re: Modifying installXX.iso via script
Thomas Bohl writes: > Am 17.11.2019 um 19:51 schrieb cho...@jtan.com: > > Thomas Bohl writes: > >> > >> Now I want to go the extra step and automate the modification of the > >> installXX.iso. > > > > I have put an insane amount of work into exactly this, also with > > an eye to portably directing the process to other operating systems > > and hosting environments. > > Thank you for your quick response. It works now. Even better that the > tools in base are enough. > > > > > I'd be very interested to hear more about what your working on but > > Nothing special. Only private stuff. I want to move from to-do lists to > scripts. I believe the buzzword is "infrastructure as code" :-) That is indeed one of the many. Personally I call it "my job" and am doing my level best to replace myself with a very small shell script. Currently down to ~3000 lines. Matthew
Re: Modifying installXX.iso via script
Thanks. For completeness what I did for now: # vnconfig vnd0 install66.iso # mount -t cd9660 /dev/vnd0c cd/ # cp -r cd cd2 # cp bsd-mod.rd cd2/6.6/amd64/bsd.rd # cp site66.tgz cd2/6.6/amd64/ # mkhybrid -a -R -T -L -l -d -D -N -o install66a.iso -vv -A "Unofficial OpenBSD 6.6 amd64 autoinstall CD" -P "Copyright (c) 2019 Theo de Raadt, The OpenBSD project" -p "Thomas Bohl " -V "Unofficial OpenBSD/amd64 6.6 CD" -b 6.6/amd64/cdbr -c 6.6/amd64/boot.catalog cd2
Re: Modifying installXX.iso via script
Am 17.11.2019 um 19:51 schrieb cho...@jtan.com:
Thomas Bohl writes:
Now I want to go the extra step and automate the modification of the
installXX.iso.
I have put an insane amount of work into exactly this, also with
an eye to portably directing the process to other operating systems
and hosting environments.
Thank you for your quick response. It works now. Even better that the
tools in base are enough.
I'd be very interested to hear more about what your working on but
Nothing special. Only private stuff. I want to move from to-do lists to
scripts. I believe the buzzword is "infrastructure as code" :-)
meanwhile I think the command you're looking for is some variant
on this:
mkiso() {
Thanks. For completeness what I did for now:
# vnconfig vnd0 install66.iso
# mount -t cd9660 /dev/vnd0c cd/
# cp -r cd cd2
# mkhybrid -a -R -T -L -l -d -D -N -o install66a.iso -vv -A "Unofficial
OpenBSD 6.6 amd64 autoinstall CD" -P "Copyright (c) 2019 Theo de Raadt,
The OpenBSD project" -p "Thomas Bohl " -V "Unofficial
OpenBSD/amd64 6.6 CD" -b 6.6/amd64/cdbr -c 6.6/amd64/boot.catalog cd2
Re: Modifying installXX.iso via script
Thomas Bohl writes:
>
> Now I want to go the extra step and automate the modification of the
> installXX.iso.
I have put an insane amount of work into exactly this, also with
an eye to portably directing the process to other operating systems
and hosting environments.
I'd be very interested to hear more about what your working on but
meanwhile I think the command you're looking for is some variant
on this:
mkiso() {
# Create new iso
# From src/distrib/amd64/cdfs/Makefile
if on_openbsd; then
OSREV=$os_version # For easier copy pasta
mkhybrid -a -R -T -L -l -d -D -N -o "$iso_fn" -v -v\
-A "OpenBSD ${OSREV} amd64 autoinstall CD" \
-P "Copyright (c) `date +%Y` Theo de Raadt, The OpenBSD project" \
-p "Theo de Raadt " \
-V "OpenBSD/amd64 ${OSREV} boot-only CD" \
-b ${OSREV}/amd64/cdbr -c ${OSREV}/amd64/boot.catalog\
"$s_where"/cd
# -a all-files
# -R Rock Ridge
# -T TRANS.TBL
# -L Allow .-file
# -l allow 32char
# -d Omit trailing period
# -D not use deep directory relocation, ... Use with caution.
# -N Omit os_version numbers ... Use with caution.
# -o "$iso_fn"
# -v -v verbose
# -b boot_image
# -c boot_catalog
else
die_unsupported build/target combination
fi
}
mkhybrid and xorriso are basically the same tool in ways I can't
quite remember right not but could probably be persuaded to. An
invocation of one can be systematically converted into an invocation
of the other.
Enjoy.
Matthew
Modifying installXX.iso via script
Hello list, I created an autoinstall bsd.rd (containing auto_install.conf and disklabel.conf) and a siteXX.tgz. For example with the tool isomaster I can manually edit the install66.iso and add bsd.rd and site66.tgz to the directory 6.6/amd64. This modified ISO can be booted from real and virtual hardware. The unattended installation works and is really cool! Now I want to go the extra step and automate the modification of the installXX.iso. I tried the tool xorriso: $ ls -l 6.6/amd64/ total 28544 -rwxr-xr-x 1 null null 10299545 Nov 17 18:00 bsd.rd -rw-r--r-- 1 null null 4680444 Nov 17 05:03 site66.tgz $ xorriso -indev install66.iso -outdev install66a.iso -boot_image "any" "keep" -add 6.6/amd64/ [1] This leads to this message when trying to boot: CD-ROM: E0 Can't find /cdboot I then moved cdboot from 6.6/amd64 to the root of the CD: $ xorriso -indev install66.iso -outdev install66a.iso -boot_image "any" "keep" -move 6.6/amd64/cdboot cdboot -add 6.6/amd64/ This leads to this message when trying to boot: CD-ROM: E0 Loading /CDBOOT probing: pc0 mem[639KB 2046M a20=on] disk: hd0+ cd0 >> OpenBSD/amd64 CDBOOT 3.44 boot> cannot open cd0a:/etc/random.seed: No such file or directory booting cd0a:/6.6/amd64/bsd.rd: open cd0a:/6.6/amd64/bsd.rd: No such file or dir ectory failed(2). will try /6.6/amd64/bsd.rd boot> When I move bsd.rd to the root of the CD too, I can at least start the installation by typing boot> bsd.rd But it would be nice if that wouldn't be necessary. When looking at the ISO files with isomatser, the only difference I can find is that on the modified ISO the publisher information is in all caps. I'm obviously doing something wrong. Any ideas or alternatives? [1] In case the full output is necessary: $ xorriso -indev install66.iso -outdev install66a.iso -boot_image "any" "keep" -add 6.6/amd64/ xorriso 1.4.8 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Loading ISO image tree from LBA 0 xorriso : UPDATE : 24 nodes read in 1 seconds xorriso : NOTE : Detected El-Torito boot information which currently is set to be discarded Drive current: -indev 'install66.iso' Media current: stdio file, overwriteable Media status : is written , is appendable Boot record : El Torito Media summary: 1 session, 226537 data blocks, 442m data, 62.8g free Volume id : 'OpenBSD/amd64 6.6 Install CD' Drive current: -outdev 'install66a.iso' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 62.8g free Added to ISO image: directory '/6.6/amd64'='/home/null/OpenBSD66/6.6/amd64' xorriso : UPDATE : 2 files added in 1 seconds xorriso : NOTE : Keeping boot image unchanged xorriso : UPDATE : Writing: 2000s 0.9% fifo 43% buf 50% xorriso : UPDATE : Writing: 23513s 10.3% fifo 84% buf 50% 32.1xD xorriso : UPDATE : Writing: 45822s 20.0% fifo 98% buf 50% 33.3xD xorriso : UPDATE : Writing: 68243s 29.8% fifo 99% buf 50% 33.5xD xorriso : UPDATE : Writing: 93008s 40.6% fifo 100% buf 50% 33.3xD xorriso : UPDATE : Writing: 114511s 50.0% fifo 99% buf 50% 32.1xD xorriso : UPDATE : Writing: 133184s 58.2% fifo 99% buf 50% 27.9xD xorriso : UPDATE : Writing: 154835s 67.6% fifo 100% buf 50% 32.3xD xorriso : UPDATE : Writing: 176528s 77.1% fifo 99% buf 50% 32.4xD xorriso : UPDATE : Writing: 197248s 86.1% fifo 99% buf 50% 30.9xD xorriso : UPDATE : Writing: 218688s 95.5% fifo 100% buf 50% 32.0xD ISO image produced: 228822 sectors Written to medium : 228992 sectors at LBA 32 Writing to 'install66a.iso' completed successfully.
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On 2019-10-29, List wrote: > I think what causes the problem is rspamd which uses JITs. These JITS > break W^X. If you enable rspamd etc on boot by (rcctl enable ...). And > reboot.. This is incorrect. rspamd uses luajit (on arches where it's available), but it is not a requirement that every JIT compiler makes W+X mappings - in particular luajit *does* work with W^X.
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
* List le [29-10-2019 21:44:43 +0100]:
> On Sun, 27 Oct 2019 21:29:41 -0700
> Jordan Geoghegan wrote:
>
> > On 2019-10-27 17:29, Chris Narkiewicz wrote:
> > > Rspamd stop rc script doesn't work in OpenBSD 6.6.
> > >
> > > 1. Fresh OpenBSD 6.6 installation
> > > 2. pkg_add rspamd
> > > 3. rcctl start rspamd
> > >
> > > Works.
> > >
> > > 4. rcctl stop rspamd timeouts
> > >
> > > Looking at rspamd logs, it looks like it doesn not work
> > > well with SIGTERM. It waits for workers.
> > >
> > > Currently I work around it by adding custom rc_stop():
> > >
> > > rc_stop() {
> > > pkill -KILL -T "${daemon_rtable}" -xf "${pexp}"
> > > pkill -KILL -u _rspamd
> > > }
> > >
> > >
> > > Anybody can confirm if this is a problem?
> > >
> >
Confirm, I had this issue too and must kill rspamd manually.
--
prx
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On Sun, 27 Oct 2019 21:29:41 -0700
Jordan Geoghegan wrote:
> On 2019-10-27 17:29, Chris Narkiewicz wrote:
> > Rspamd stop rc script doesn't work in OpenBSD 6.6.
> >
> > 1. Fresh OpenBSD 6.6 installation
> > 2. pkg_add rspamd
> > 3. rcctl start rspamd
> >
> > Works.
> >
> > 4. rcctl stop rspamd timeouts
> >
> > Looking at rspamd logs, it looks like it doesn not work
> > well with SIGTERM. It waits for workers.
> >
> > Currently I work around it by adding custom rc_stop():
> >
> > rc_stop() {
> > pkill -KILL -T "${daemon_rtable}" -xf "${pexp}"
> > pkill -KILL -u _rspamd
> > }
> >
> >
> > Anybody can confirm if this is a problem?
> >
>
> Yes, can confirm. I think I read something the other day mentioning
> sthen@ possibly having a diff floating around to fix the issue.
> Hopefully the fix will be backported to -stable.
>
Hi,
I am myself running a MX that uses rspamd + postfix.
I did have the same issue. Especially when running rspamd and adding
redis to the setup.
I think what causes the problem is rspamd which uses JITs. These JITS
break W^X. If you enable rspamd etc on boot by (rcctl enable ...). And
reboot.. Everything works fine. At least for me did.
Don't hesitate asking.
Kind regards,
Stephan
Re: rspamd stop rc script doesn't work in OpenBSD 6.6
On 2019-10-27 17:29, Chris Narkiewicz wrote:
Rspamd stop rc script doesn't work in OpenBSD 6.6.
1. Fresh OpenBSD 6.6 installation
2. pkg_add rspamd
3. rcctl start rspamd
Works.
4. rcctl stop rspamd timeouts
Looking at rspamd logs, it looks like it doesn not work
well with SIGTERM. It waits for workers.
Currently I work around it by adding custom rc_stop():
rc_stop() {
pkill -KILL -T "${daemon_rtable}" -xf "${pexp}"
pkill -KILL -u _rspamd
}
Anybody can confirm if this is a problem?
Yes, can confirm. I think I read something the other day mentioning
sthen@ possibly having a diff floating around to fix the issue.
Hopefully the fix will be backported to -stable.
sysupgrade script diff for people with small /home
Hi,
see $subj, some people have so small /home and currently sysupgrade
doesn't like symlink to bigger partition. (I know that bad symlink can
make it explode.)
--- /usr/sbin/sysupgrade.orig Mon Aug 12 19:07:11 2019
+++ /usr/sbin/sysupgradeMon Aug 12 18:51:28 2019
@@ -119,6 +119,7 @@ else
fi
if [[ -e ${SETSDIR} ]]; then
+ [[ -h ${SETSDIR} ]] && SETSDIR=$(readlink -f $SETSDIR)
eval $(stat -s ${SETSDIR})
[[ $st_uid -eq 0 ]] ||
ug_err "${SETSDIR} needs to be owned by root:wheel"
j.
vidoas script
howdee,
i know that yallve helped me so many times
and in so many ways that i thought id try to
give something back... in particular i have
run into the simple/silly problem of directly
editting the /etc/doas.conf file and making a
mistake which locks me out of fixing it...
so, i looked around for a vipw/visudo type of
script - and not seeing one; i came up with
the following variant... im sure there are other
(and better?) ways to do this task - so feel
free to do whatever you please with this script...
(ie - if there must be some-license associated,
use: https://choosealicense.com/licenses/unlicense/ ?)
hope this helps someone else... h.
#!/bin/ksh
#
# hjf latest mod: 2019-08-05 @ 10:00
#
## vidoas.sh
#
## this is a basic copy/update from eradman at
## http://eradman.com/postst/ut-shell-scripts.html
##
## GOAL try to create a vidoas pgm like visudo...
export LAUNCH_CMDS=`mktemp`
export VI_FILE=`mktemp`
export USR=`whoami`
export TTY=`tty`
export DOASFILE="/etc/doas.conf"
typeset -i test_runs=0
function try { this="$1"; }
trap 'printf "$0: exit code $? on line $LINENO\nFAIL: $this\n"; exit 1' ERR
function assert {
let tests_run+=1
[ "$1" = "$2" ] && { echo -n "."; return; }
printf "\nFAIL: $this\n'$1' != '$2'\n"; exit 1
}
try "1. create an edit-able copy..."
cat > $LAUNCH_CMDS <<-'LAUNCHER'
doas -L
doas cp $DOASFILE $VI_FILE
doas -L
LAUNCHER
# syserr catches bad passwords here...
assert "`. $LAUNCH_CMDS 2>&1`" ""
try "2. go ahead and vi-edit ..."
cat > $LAUNCH_CMDS <<-'LAUNCHER'
# dont let kshrc-stuff run...
export ENV=''
( ksh -i -c "vi $VI_FILE <$TTY >$TTY" )
doas -C $VI_FILE
LAUNCHER
# check blatant errors in editting...
assert "`. $LAUNCH_CMDS 2>&1`" ""
try "3. post-edit-check for replacement permissions..."
assert "`doas -C $VI_FILE -u $USR cp | cut -c 1-6 `" "permit"
try "4. install the latest-greatest back..."
assert "`doas cp $VI_FILE $DOASFILE 2>&1`" ""
rm -f $LAUNCH_CMDS
rm -f $VI_FILE
##echo; echo "PASS: $tests_run tests run"
echo "vidoas.sh succeeded."
Re: Correct pexp variable for a shell script
On 6/29/19 8:46 AM, Antoine Jacoutot wrote: > On Sat, Jun 22, 2019 at 02:14:12PM -0400, Jacob Adams wrote: >> On 6/22/19 12:43 PM, Antoine Jacoutot wrote: >>> On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote: >>>> On 6/22/19 7:05 AM, Antoine Jacoutot wrote: >>>>> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: >>>>>> I've got a shell script I'd like to run as a system service. Due to the >>>>>> 16 character limitation on pgrep and the -x flag that rc.subr passes to >>>>>> check by default, I can't get check or stop to work correctly. The >>>>>> problem is that the process name looks like "/bin/sh >>>>>> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match >>>>>> when -x is used. >>>>>> >>>>>> My rc.d script currently looks like this: >>>>>> >>>>> Hi. >>>>> >>>>> That should not be an issue, that's why pexp is used for. >>>>> But without more context it's hard to know how to help you. >>>>> >>>>> I can match sh scripts without issue: >>>>> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" >>>>> 77289 >>>>> >>>>> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? >>>>> We don't run into the 16 chars limitation when using -xf >>>> Here's what I was seeing that led me to that conclusion: >>>> >>>> rukey$ ps aux | grep authmail >>>> root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 >>>> /bin/sh /usr/local/bin/authmail >>>> jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep >>>> authmail >>>> rukey$ pgrep -f /bin/sh /usr/local/bin/authmail >>>> 51889 >>>> rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail >>>> >>>> >>>> However, I didn't think to quote it. that seems to fix it: >>>> >>>> rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" >>>> 51889 >>>> >>>> It appears that rc.subr uses quotes, but: >>>> >>>> rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" >>>> 51889 >>>> rukey# rcctl check authmail >>>> authmail(failed) >>>> rukey# >>>> >>>> Any idea what could be going wrong here? >>> Dunno, run rcctl in debug mode. >> >> rukey# ps ux | grep authmail >> root 93772 0.0 0.2 272 892 p0 S+p 2:10PM 0:00.01 grep >> authmail >> rukey# rcctl -d start authmail >> doing _rc_parse_conf >> doing _rc_quirks >> authmail_flags empty, using default >< >> doing _rc_parse_conf /var/run/rc.d/authmail >> doing _rc_quirks >> doing rc_check >> authmail >> doing rc_start >> doing _rc_wait start >> doing rc_check >> doing rc_check > Can you share you /var/run/rc.d/authmail file please. That seems to be the problem daemon_class=daemon daemon_flags= daemon_rtable=0 daemon_timeout=30 daemon_user=root pexp=/usr/local/bin/authmail.sh Deleting that file and restarting authmail fixed the issue, allowing me to start authmail successfully Thanks for your help! Jacob
Re: Correct pexp variable for a shell script
On Sat, Jun 22, 2019 at 02:14:12PM -0400, Jacob Adams wrote: > > On 6/22/19 12:43 PM, Antoine Jacoutot wrote: > > On Sat, Jun 22, 2019 at 10:42:39AM -0400, Jacob Adams wrote: > >> On 6/22/19 7:05 AM, Antoine Jacoutot wrote: > >>> On Fri, Jun 21, 2019 at 03:57:41PM -0400, Jacob Adams wrote: > >>>> I've got a shell script I'd like to run as a system service. Due to the > >>>> 16 character limitation on pgrep and the -x flag that rc.subr passes to > >>>> check by default, I can't get check or stop to work correctly. The > >>>> problem is that the process name looks like "/bin/sh > >>>> /usr/local/bin/script.sh" which, even if passed to pgrep, won't match > >>>> when -x is used. > >>>> > >>>> My rc.d script currently looks like this: > >>>> > >>> Hi. > >>> > >>> That should not be an issue, that's why pexp is used for. > >>> But without more context it's hard to know how to help you. > >>> > >>> I can match sh scripts without issue: > >>> $ pgrep -xf "/bin/sh /etc/gdm/Xsession /usr/local/bin/gnome-session" > >>> 77289 > >>> > >>> Are you sure your entire process line is "bin/sh /usr/local/bin/authmail"? > >>> We don't run into the 16 chars limitation when using -xf > >> > >> Here's what I was seeing that led me to that conclusion: > >> > >> rukey$ ps aux | grep authmail > >> root 51889 0.0 0.1 724 568 p0- Ip Fri12AM 0:00.01 > >> /bin/sh /usr/local/bin/authmail > >> jacob 25510 0.0 0.2 272 892 p0 S+p 10:36AM 0:00.01 grep > >> authmail > >> rukey$ pgrep -f /bin/sh /usr/local/bin/authmail > >> 51889 > >> rukey$ pgrep -xf /bin/sh /usr/local/bin/authmail > >> > >> > >> However, I didn't think to quote it. that seems to fix it: > >> > >> rukey$ pgrep -xf "/bin/sh /usr/local/bin/authmail" > >> 51889 > >> > >> It appears that rc.subr uses quotes, but: > >> > >> rukey# pgrep -xf "/bin/sh /usr/local/bin/authmail" > >> 51889 > >> rukey# rcctl check authmail > >> authmail(failed) > >> rukey# > >> > >> Any idea what could be going wrong here? > > Dunno, run rcctl in debug mode. > > > rukey# ps ux | grep authmail > root 93772 0.0 0.2 272 892 p0 S+p 2:10PM 0:00.01 grep > authmail > rukey# rcctl -d start authmail > doing _rc_parse_conf > doing _rc_quirks > authmail_flags empty, using default >< > doing _rc_parse_conf /var/run/rc.d/authmail > doing _rc_quirks > doing rc_check > authmail > doing rc_start > doing _rc_wait start > doing rc_check > doing rc_check Can you share you /var/run/rc.d/authmail file please. -- Antoine
