Re: Another potential ksh bug?
On 07/12/2020 05:41, Jordan Geoghegan wrote:
Hello again,
I was playing around with ksh array syntax and its behaviour when set
as read-only. In my testing I noticed that ksh will allow you to
overwrite the first element of a read-only array. Example snippet:
#!/bin/ksh
arr[0]=val1
arr[1]=val2
readonly arr
echo "${arr[@]}"
arr=yikes
echo "${arr[@]}"
I tested a few other shells, and this bug does exists in the original
pdksh and is also present in zsh. This bug is not present in ksh93,
mksh or bash, where they abort when trying to modify the read-only array.
I don't have access to a proper ksh88 shell, but it would be nice if
someone could confirm its behaviour.
I was just hoping someone could confirm if this is intended behaviour,
or if it's a bug.
Regards,
Jordan
Hi,
I tries this with AMIX (UNIX SVR4 for Commodore Amiga) v2.1 which
presumably is using ksh88 as it hasn't been updated since circa 1992 and
it does abort at the same place. Screenshot here:
http://casper.nineinchnetworks.ch/images/kshtest.png .
Cheers,
Noth
Re: Another potential ksh bug?
For me, this is a definite bug. I've opted my students to fix this
bug, so unless there's a hurry, there must be a fix till the end of
December. :)
пн, 7 дек. 2020 г. в 07:43, Jordan Geoghegan :
>
> Hello again,
>
> I was playing around with ksh array syntax and its behaviour when set as
> read-only. In my testing I noticed that ksh will allow you to overwrite
> the first element of a read-only array. Example snippet:
>
> #!/bin/ksh
> arr[0]=val1
> arr[1]=val2
> readonly arr
> echo "${arr[@]}"
> arr=yikes
> echo "${arr[@]}"
>
> I tested a few other shells, and this bug does exists in the original
> pdksh and is also present in zsh. This bug is not present in ksh93, mksh
> or bash, where they abort when trying to modify the read-only array.
>
> I don't have access to a proper ksh88 shell, but it would be nice if
> someone could confirm its behaviour.
>
> I was just hoping someone could confirm if this is intended behaviour,
> or if it's a bug.
>
> Regards,
>
> Jordan
>
--
WBR,
Vadim Zhukov
Re: pflogd write /var/run/mypflogdinstance.pid?
Yep.
It is possible we need a better strategy --- like placing *all* original
argv in the [priv] title.
trondd wrote:
> Stuart Henderson wrote:
>
> > On 2020-12-07, Harald Dunkel wrote:
> > > About the PIDs: Maybe a systctl like
> > >
> > > kernel.pid_max = 4194303
> > >
> > > known from other OSes could help to reduce the risk for PID conflicts.
> >
> > This doesn't help if you actually want reliability, rather than just
> > "reliable most of the time".
> >
> > There were also some concerns about what software would do with long
> > PIDs - even on a very basic level that adds another couple of columns
> > to top(1) output.
> >
> > > If you store the PID files on a volatile file system, so you can be sure
> > > they are gone on the next reboot, anyway.
> >
> > /var/run is cleared at boot anyway - the problem is pid reuse during
> > uptime of the system.
> >
> > One can check that the new pid is owned by a process of the correct name
> > - but then the problem returns, the process name doesn't have enough
> > information to uniquely identify it. And if that is fixed there's no
> > need to save the pid.
> >
> > So if there's a problem to be fixed, it is to get the information into
> > the other process string..
>
> I think the user is looking for something like this. Putting the interface
> name in the process title.
>
> Mabe this doesn't work for this use case or there is some other fallout.
> And there may be other tweaks needed to support it, I don't have a dog in the
> fight to go find them, though.
>
> Tim.
>
>
> Index: etc/rc.d/pflogd
> ===
> RCS file: /cvs/src/etc/rc.d/pflogd,v
> retrieving revision 1.3
> diff -u -p -r1.3 pflogd
> --- etc/rc.d/pflogd 11 Jan 2018 19:52:12 - 1.3
> +++ etc/rc.d/pflogd 7 Dec 2020 18:08:23 -
> @@ -6,7 +6,7 @@ daemon="/sbin/pflogd"
>
> . /etc/rc.d/rc.subr
>
> -pexp="pflogd: \[priv\]"
> +pexp="pflogd: \[priv\].*"
>
> rc_pre() {
> if pfctl -si | grep -q Enabled; then
> Index: sbin/pflogd/privsep.c
> ===
> RCS file: /cvs/src/sbin/pflogd/privsep.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 privsep.c
> --- sbin/pflogd/privsep.c 27 Nov 2019 17:49:09 - 1.34
> +++ sbin/pflogd/privsep.c 7 Dec 2020 18:08:45 -
> @@ -131,7 +131,7 @@ priv_init(int Pflag, int argc, char *arg
> signal(SIGINT, sig_pass_to_chld);
> signal(SIGQUIT, sig_pass_to_chld);
>
> - setproctitle("[priv]");
> + setproctitle("[priv] %s", interface);
>
> if (unveil(_PATH_RESCONF, "r") == -1)
> err(1, "unveil");
>
Re: pflogd write /var/run/mypflogdinstance.pid?
Stuart Henderson wrote:
> On 2020-12-07, Harald Dunkel wrote:
> > About the PIDs: Maybe a systctl like
> >
> > kernel.pid_max = 4194303
> >
> > known from other OSes could help to reduce the risk for PID conflicts.
>
> This doesn't help if you actually want reliability, rather than just
> "reliable most of the time".
>
> There were also some concerns about what software would do with long
> PIDs - even on a very basic level that adds another couple of columns
> to top(1) output.
>
> > If you store the PID files on a volatile file system, so you can be sure
> > they are gone on the next reboot, anyway.
>
> /var/run is cleared at boot anyway - the problem is pid reuse during
> uptime of the system.
>
> One can check that the new pid is owned by a process of the correct name
> - but then the problem returns, the process name doesn't have enough
> information to uniquely identify it. And if that is fixed there's no
> need to save the pid.
>
> So if there's a problem to be fixed, it is to get the information into
> the other process string..
I think the user is looking for something like this. Putting the interface
name in the process title.
Mabe this doesn't work for this use case or there is some other fallout.
And there may be other tweaks needed to support it, I don't have a dog in the
fight to go find them, though.
Tim.
Index: etc/rc.d/pflogd
===
RCS file: /cvs/src/etc/rc.d/pflogd,v
retrieving revision 1.3
diff -u -p -r1.3 pflogd
--- etc/rc.d/pflogd 11 Jan 2018 19:52:12 - 1.3
+++ etc/rc.d/pflogd 7 Dec 2020 18:08:23 -
@@ -6,7 +6,7 @@ daemon="/sbin/pflogd"
. /etc/rc.d/rc.subr
-pexp="pflogd: \[priv\]"
+pexp="pflogd: \[priv\].*"
rc_pre() {
if pfctl -si | grep -q Enabled; then
Index: sbin/pflogd/privsep.c
===
RCS file: /cvs/src/sbin/pflogd/privsep.c,v
retrieving revision 1.34
diff -u -p -r1.34 privsep.c
--- sbin/pflogd/privsep.c 27 Nov 2019 17:49:09 - 1.34
+++ sbin/pflogd/privsep.c 7 Dec 2020 18:08:45 -
@@ -131,7 +131,7 @@ priv_init(int Pflag, int argc, char *arg
signal(SIGINT, sig_pass_to_chld);
signal(SIGQUIT, sig_pass_to_chld);
- setproctitle("[priv]");
+ setproctitle("[priv] %s", interface);
if (unveil(_PATH_RESCONF, "r") == -1)
err(1, "unveil");
Re: pflogd write /var/run/mypflogdinstance.pid?
Stuart Henderson wrote: > On 2020-12-07, Harald Dunkel wrote: > > About the PIDs: Maybe a systctl like > > > > kernel.pid_max = 4194303 > > > > known from other OSes could help to reduce the risk for PID conflicts. > > This doesn't help if you actually want reliability, rather than just > "reliable most of the time". > > There were also some concerns about what software would do with long > PIDs - even on a very basic level that adds another couple of columns > to top(1) output. Yep. Also expanding the pid range increases the cost of allocpid(), so fork() becomes slower. > > If you store the PID files on a volatile file system, so you can be sure > > they are gone on the next reboot, anyway. > > /var/run is cleared at boot anyway - the problem is pid reuse during > uptime of the system. > > One can check that the new pid is owned by a process of the correct name > - but then the problem returns, the process name doesn't have enough > information to uniquely identify it. And if that is fixed there's no > need to save the pid. > > So if there's a problem to be fixed, it is to get the information into > the other process string.. It is worth considering what the 'lifetime' of a pid number. It is a unique number while the process is running. After it runs, the number is immediately available for reuse. There is no lazy "don't use that number yet, wait a while" scheme (adding such a scheme in OpenBSD would not solve the general problem).
Re: clock not set on boot
On 05/12/2020, Patrick Wildt wrote: > > -s doesn't exist anymore. > ... and other replies... You've all proved what I guess I already knew. I don't live in the world anymore. It just passes me by.
Re: pflogd write /var/run/mypflogdinstance.pid?
On 2020-12-07, Harald Dunkel wrote: > About the PIDs: Maybe a systctl like > > kernel.pid_max = 4194303 > > known from other OSes could help to reduce the risk for PID conflicts. This doesn't help if you actually want reliability, rather than just "reliable most of the time". There were also some concerns about what software would do with long PIDs - even on a very basic level that adds another couple of columns to top(1) output. > If you store the PID files on a volatile file system, so you can be sure > they are gone on the next reboot, anyway. /var/run is cleared at boot anyway - the problem is pid reuse during uptime of the system. One can check that the new pid is owned by a process of the correct name - but then the problem returns, the process name doesn't have enough information to uniquely identify it. And if that is fixed there's no need to save the pid. So if there's a problem to be fixed, it is to get the information into the other process string..
Re: pflogd write /var/run/mypflogdinstance.pid?
On 12/7/20 7:43 AM, Theo de Raadt wrote:
We've put some work into making programs not damage their argv. If you
provide a strong set of arguments to the programs you start, you may be
able to pkill with a more fullsize pattern, increasing the accuracy.
AFAICS pflogd rewrites the command line. This is what I saw this morning
for using symlinks:
{root@gate6a:etc 510} ps auxww | grep pflogd
root 8647 0.0 0.0 716 576 ?? IU 27Nov200:00.00 pflogd0:
[priv] (pflogd)
_pflogd 44379 0.0 0.0 772 652 ?? Sp 27Nov200:19.26 pflogd0:
[running] -s 160 -i pflog0 -f /var/log/pflog0 (pflogd)
root 23720 0.0 0.0 732 596 ?? IU 27Nov200:00.00 pflogd1:
[priv] (pflogd)
_pflogd 22050 0.0 0.0 772 660 ?? Sp 27Nov200:22.99 pflogd1:
[running] -s 160 -i pflog1 -f /var/log/pflog1 (pflogd)
root 52274 0.0 0.0 724 588 ?? IU 27Nov200:00.00 pflogd2:
[priv] (pflogd)
_pflogd 26070 0.0 0.0 772 564 ?? Sp 27Nov200:15.02 pflogd2:
[running] -s 160 -i pflog2 -f /var/log/pflog2 (pflogd)
root 10820 0.0 0.0 732 576 ?? IU 27Nov200:00.00 pflogd3:
[priv] (pflogd)
_pflogd 75291 0.0 0.0 772 564 ?? Sp 27Nov200:14.70 pflogd3:
[running] -s 160 -i pflog3 -f /var/log/pflog3 (pflogd)
root 87921 0.0 0.0 108 280 p0 R+/36:03AM0:00.00 grep pflogd
newsyslog has to kill -HUP the processes owned by root. See that there
is just "pflogd" possible as a search pattern for pkill? Using "pflogd3"
as a search pattern didn't work, so I had to replace the symlinks by
hard links to make "pflogd3" show up in the process table.
Surely I am not askting to drop pkill or pgrep. But an optional
argument -p in pflogd shouldn't hurt. Nobody is forced to use it.
(Not to mention that "pkill pflogd" would kill a process "pflogdsample"
as well, so there is still a risk for killing the wrong process.)
About the PIDs: Maybe a systctl like
kernel.pid_max = 4194303
known from other OSes could help to reduce the risk for PID conflicts.
If you store the PID files on a volatile file system, so you can be sure
they are gone on the next reboot, anyway.
Just a suggestion, of course. Please keep on your good work
Regards
Harri
