On 12/13/20 8:32 PM, Theo de Raadt wrote:
If a pflogd dies because of a bug, the pid listed in the file may be
reused, and then your kill `cat pidfile` will kill the incorrect process.
I understand your concern, but as written before, I am not asking to drop
pkill support.
How about adding
>> On 2020-12-13, Harald Dunkel wrote:
> On 12/13/20 7:10 PM, Theo de Raadt wrote:
>>
>> And I'm suggesting the arguments should look like this:
>>
>> pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
>> pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
>>
>> That
On Sun, Dec 13, 2020 at 08:24:13PM -, Stuart Henderson wrote:
> On 2020-12-13, Harald Dunkel wrote:
> > On 12/13/20 7:10 PM, Theo de Raadt wrote:
> >>
> >> And I'm suggesting the arguments should look like this:
> >>
> >> pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
> >>
On 2020-12-13, Harald Dunkel wrote:
> On 12/13/20 7:10 PM, Theo de Raadt wrote:
>>
>> And I'm suggesting the arguments should look like this:
>>
>> pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
>> pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
>>
>> That
On Sun, Dec 13, 2020 at 10:42:20PM +0300, Consus wrote:
On Sun, Dec 13, 2020 at 08:27:24PM +0100, Harald Dunkel wrote:
At least OpenBSD is not alone with this problem. On Debian there
is a tool "/bin/pidof", trying to guess the pid of a daemon to kill
by looking at the process list as well.
On Sun, Dec 13, 2020 at 08:27:24PM +0100, Harald Dunkel wrote:
At least OpenBSD is not alone with this problem. On Debian there
is a tool "/bin/pidof", trying to guess the pid of a daemon to kill
by looking at the process list as well.
Some dude from Google came up with a good solution (for
Harald Dunkel wrote:
> On 12/13/20 7:10 PM, Theo de Raadt wrote:
> >
> > And I'm suggesting the arguments should look like this:
> >
> > pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
> > pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
> >
> > That might allow
On 12/13/20 7:10 PM, Theo de Raadt wrote:
And I'm suggesting the arguments should look like this:
pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
That might allow more accurate pkill targetting.
Wouldn't you
Harald Dunkel wrote:
> On 12/7/20 7:19 PM, Theo de Raadt wrote:
> > Yep.
> >
> > It is possible we need a better strategy --- like placing *all* original
> > argv in the [priv] title.
> >
>
> If you change the pflogd command line in the process list, what is
> supposed to happen to the existing
On 12/7/20 7:19 PM, Theo de Raadt wrote:
Yep.
It is possible we need a better strategy --- like placing *all* original
argv in the [priv] title.
If you change the pflogd command line in the process list, what is
supposed to happen to the existing code using pkill or pgrep, expecting
the
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
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
>
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
>
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
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
Harald Dunkel wrote:
> Hi folks,
>
> I have to run several pflogd in parallel. To make pkill (i.e.
> newsyslog) work it seems to be necessary to create hard links
> pflogd1, pflogd2 etc., pointing to /sbin/pflogd. Soft links
> don't work, because they don't show up in the process table.
> This
Hi folks,
I have to run several pflogd in parallel. To make pkill (i.e.
newsyslog) work it seems to be necessary to create hard links
pflogd1, pflogd2 etc., pointing to /sbin/pflogd. Soft links
don't work, because they don't show up in the process table.
This introduces new problems on the next
17 matches
Mail list logo
