Re: www/squid does not shutdown via rc

2015-02-02 Thread Kevin Oberman 
On Mon, Feb 2, 2015 at 11:00 AM, Nick Rogers ncrog...@gmail.com wrote:



 On Fri, Jan 30, 2015 at 8:51 PM, Kevin Oberman rkober...@gmail.com
 wrote:

 On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt pvo...@uos.de wrote:

  On Tue, 27 Jan 2015 11:51:51 +0100
  Marko Cupać marko.cu...@mimar.rs wrote:
 
   On Tue, 27 Jan 2015 07:11:10 +
   Matthew Seaman matt...@freebsd.org wrote:
  
On 2015/01/27 03:52, Kurt Jaeger wrote:
 Doesn't installing a custom kernel break freebsd-update ?
   
No.  freebsd-update has always supported using a custom kernel.  It
helps if you name your kernel something other than GENERIC, which
you do by creating a modofoed kernel config file
in /usr/src/sys/amd64/conf (or i386 if that's your architecture):
eg.
   
% cat FOO
include GENERIC
   
ident FOO
   
and then add:
   
KERNCONF=   FOO
   
to /etc/make.conf
   
You should also edit /etc/freebsd-update.conf and change the
'Components' line to remove 'kernel' from the list.
   
None of this is absolutely necessary, but it will help you avoid
accidentally ending up with the generic kernel.
   
In any case, what you will need to do is rebuild your kernel and
reinstall it any time freebsd-update touches the kernel.  You can
use freebsd-update to maintain the kernel sources, which will pull
in the needed updates to the kernel sources.
  
   The timing for this is really unfortunate for me, because I have just
   re-installed my FreeBSD fleet of some 20 virtual servers without
   sources included, and I just introduced binary only policy (ok I do
   build my own ports on one server in poudriere, but all other servers
   use packages).
  
   I guess theoretically it is possible to make kernel build server
   which will build custom kernel for distribution to other servers. I
   am just not sure how will RELEASE userland tolerate STABLE kernel.
  
   Does this sound reasonable? Any tips?
  
   Thank you in advance,
 
  Thanks to all who contributed to this thread.
 

 Sorry for the late response. I've had guests for hte past few days and
 simply have not had time to properly address your concerns.

 While most of these concerns are not an issue, exactly why gets a bit more
 complex. And there are some real issues, but this is an exceptionally
 simple case and eliminates most of them. See comments in-line.

 
  @Kevin:
  Your outline of kernel patching procedure is helpful and corresponds
  in most aspects what I have thought so far. I aggree with you that
  patching, building and installing a custom kernel can be managed. And I
  am sure that I can do it.
 
  So getting a custom kernel installed is one thing but keeping your
  system in a manageable way is another. Kurt and Mattew pointed out that
  you want to keep freebsd-update working in a reliable way and this
  obviously needs some manual interaction. Information about it is
  not too easily gathered and answers given here still leave some
  question open to me.
 

 It does, but very little. In general, freebsd-update is a binary update
 tool. While it does update sources, if they are present, it makes no use
 of
 those sources.

 My instructions provided for saving the GENERIC kernel where
 freebsd-update
 will use it instead of the running kernel. /boot/GENERIC is used only be
 freebsd-update. It is otherwise unneeded. This does not touch any files
 that will normally require merging, which is often the main complication.
 I
 am unsure whether it will require a merge of the modified source files,
 but
 that is easily avoidable renaming /sys/kern/kern_sig.c.orig to overwrite
 the patched /sys/kern/kern_sig.c file, returning the sources to their
 original condition.
 # cp /sys/kern/kern_sig.c.orig /sys/kern/kern_sig.c

 This is not really required, but will assure that, from the perspective of
 freebsd-update, the system will be entirely unchanged. There is simply no
 impact on future updates as there are no changes left.


  I have had a hard time with freebsd-update when upgrading 10.0-RELEASE
  - 10.1-RELEASE:
 
 
 https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094
  and I do not want to get even more trouble letting
  freebsd-update confuse my system with a mixture of GENERIC and custom
  kernels ending in a situation where none of them is able to boot.
 
  I have learned that I can advice freebsd-update to not update my kernel
  but am still confused whether it is the version under /boot/GENERIC or
  the one under /boot/kernel. And I would like to know how to tell
  FreeBSD how to boot a certain kernel. All I know so far is that if a
  kernel fails to boot you have to boot into recovery and move kernel.old
  to kernel. Is there a boot menu available with the FreeBSD boot loader
  which would simplify life a lot?
 

 The running kernel is in boot/kernel. /boot/GENERIC is not present unless
 you create it and, when

Re: www/squid does not shutdown via rc

2015-02-02 Thread Nick Rogers 
On Fri, Jan 30, 2015 at 8:51 PM, Kevin Oberman rkober...@gmail.com wrote:

 On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt pvo...@uos.de wrote:

  On Tue, 27 Jan 2015 11:51:51 +0100
  Marko Cupać marko.cu...@mimar.rs wrote:
 
   On Tue, 27 Jan 2015 07:11:10 +
   Matthew Seaman matt...@freebsd.org wrote:
  
On 2015/01/27 03:52, Kurt Jaeger wrote:
 Doesn't installing a custom kernel break freebsd-update ?
   
No.  freebsd-update has always supported using a custom kernel.  It
helps if you name your kernel something other than GENERIC, which
you do by creating a modofoed kernel config file
in /usr/src/sys/amd64/conf (or i386 if that's your architecture):
eg.
   
% cat FOO
include GENERIC
   
ident FOO
   
and then add:
   
KERNCONF=   FOO
   
to /etc/make.conf
   
You should also edit /etc/freebsd-update.conf and change the
'Components' line to remove 'kernel' from the list.
   
None of this is absolutely necessary, but it will help you avoid
accidentally ending up with the generic kernel.
   
In any case, what you will need to do is rebuild your kernel and
reinstall it any time freebsd-update touches the kernel.  You can
use freebsd-update to maintain the kernel sources, which will pull
in the needed updates to the kernel sources.
  
   The timing for this is really unfortunate for me, because I have just
   re-installed my FreeBSD fleet of some 20 virtual servers without
   sources included, and I just introduced binary only policy (ok I do
   build my own ports on one server in poudriere, but all other servers
   use packages).
  
   I guess theoretically it is possible to make kernel build server
   which will build custom kernel for distribution to other servers. I
   am just not sure how will RELEASE userland tolerate STABLE kernel.
  
   Does this sound reasonable? Any tips?
  
   Thank you in advance,
 
  Thanks to all who contributed to this thread.
 

 Sorry for the late response. I've had guests for hte past few days and
 simply have not had time to properly address your concerns.

 While most of these concerns are not an issue, exactly why gets a bit more
 complex. And there are some real issues, but this is an exceptionally
 simple case and eliminates most of them. See comments in-line.

 
  @Kevin:
  Your outline of kernel patching procedure is helpful and corresponds
  in most aspects what I have thought so far. I aggree with you that
  patching, building and installing a custom kernel can be managed. And I
  am sure that I can do it.
 
  So getting a custom kernel installed is one thing but keeping your
  system in a manageable way is another. Kurt and Mattew pointed out that
  you want to keep freebsd-update working in a reliable way and this
  obviously needs some manual interaction. Information about it is
  not too easily gathered and answers given here still leave some
  question open to me.
 

 It does, but very little. In general, freebsd-update is a binary update
 tool. While it does update sources, if they are present, it makes no use of
 those sources.

 My instructions provided for saving the GENERIC kernel where freebsd-update
 will use it instead of the running kernel. /boot/GENERIC is used only be
 freebsd-update. It is otherwise unneeded. This does not touch any files
 that will normally require merging, which is often the main complication. I
 am unsure whether it will require a merge of the modified source files, but
 that is easily avoidable renaming /sys/kern/kern_sig.c.orig to overwrite
 the patched /sys/kern/kern_sig.c file, returning the sources to their
 original condition.
 # cp /sys/kern/kern_sig.c.orig /sys/kern/kern_sig.c

 This is not really required, but will assure that, from the perspective of
 freebsd-update, the system will be entirely unchanged. There is simply no
 impact on future updates as there are no changes left.


  I have had a hard time with freebsd-update when upgrading 10.0-RELEASE
  - 10.1-RELEASE:
 
 
 https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094
  and I do not want to get even more trouble letting
  freebsd-update confuse my system with a mixture of GENERIC and custom
  kernels ending in a situation where none of them is able to boot.
 
  I have learned that I can advice freebsd-update to not update my kernel
  but am still confused whether it is the version under /boot/GENERIC or
  the one under /boot/kernel. And I would like to know how to tell
  FreeBSD how to boot a certain kernel. All I know so far is that if a
  kernel fails to boot you have to boot into recovery and move kernel.old
  to kernel. Is there a boot menu available with the FreeBSD boot loader
  which would simplify life a lot?
 

 The running kernel is in boot/kernel. /boot/GENERIC is not present unless
 you create it and, when present, it is used as the kernel which
 frebsd-update will patch in the upgrade

Re: www/squid does not shutdown via rc

2015-01-30 Thread Kevin Oberman 
On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt pvo...@uos.de wrote:

 On Tue, 27 Jan 2015 11:51:51 +0100
 Marko Cupać marko.cu...@mimar.rs wrote:

  On Tue, 27 Jan 2015 07:11:10 +
  Matthew Seaman matt...@freebsd.org wrote:
 
   On 2015/01/27 03:52, Kurt Jaeger wrote:
Doesn't installing a custom kernel break freebsd-update ?
  
   No.  freebsd-update has always supported using a custom kernel.  It
   helps if you name your kernel something other than GENERIC, which
   you do by creating a modofoed kernel config file
   in /usr/src/sys/amd64/conf (or i386 if that's your architecture):
   eg.
  
   % cat FOO
   include GENERIC
  
   ident FOO
  
   and then add:
  
   KERNCONF=   FOO
  
   to /etc/make.conf
  
   You should also edit /etc/freebsd-update.conf and change the
   'Components' line to remove 'kernel' from the list.
  
   None of this is absolutely necessary, but it will help you avoid
   accidentally ending up with the generic kernel.
  
   In any case, what you will need to do is rebuild your kernel and
   reinstall it any time freebsd-update touches the kernel.  You can
   use freebsd-update to maintain the kernel sources, which will pull
   in the needed updates to the kernel sources.
 
  The timing for this is really unfortunate for me, because I have just
  re-installed my FreeBSD fleet of some 20 virtual servers without
  sources included, and I just introduced binary only policy (ok I do
  build my own ports on one server in poudriere, but all other servers
  use packages).
 
  I guess theoretically it is possible to make kernel build server
  which will build custom kernel for distribution to other servers. I
  am just not sure how will RELEASE userland tolerate STABLE kernel.
 
  Does this sound reasonable? Any tips?
 
  Thank you in advance,

 Thanks to all who contributed to this thread.


Sorry for the late response. I've had guests for hte past few days and
simply have not had time to properly address your concerns.

While most of these concerns are not an issue, exactly why gets a bit more
complex. And there are some real issues, but this is an exceptionally
simple case and eliminates most of them. See comments in-line.


 @Kevin:
 Your outline of kernel patching procedure is helpful and corresponds
 in most aspects what I have thought so far. I aggree with you that
 patching, building and installing a custom kernel can be managed. And I
 am sure that I can do it.

 So getting a custom kernel installed is one thing but keeping your
 system in a manageable way is another. Kurt and Mattew pointed out that
 you want to keep freebsd-update working in a reliable way and this
 obviously needs some manual interaction. Information about it is
 not too easily gathered and answers given here still leave some
 question open to me.


It does, but very little. In general, freebsd-update is a binary update
tool. While it does update sources, if they are present, it makes no use of
those sources.

My instructions provided for saving the GENERIC kernel where freebsd-update
will use it instead of the running kernel. /boot/GENERIC is used only be
freebsd-update. It is otherwise unneeded. This does not touch any files
that will normally require merging, which is often the main complication. I
am unsure whether it will require a merge of the modified source files, but
that is easily avoidable renaming /sys/kern/kern_sig.c.orig to overwrite
the patched /sys/kern/kern_sig.c file, returning the sources to their
original condition.
# cp /sys/kern/kern_sig.c.orig /sys/kern/kern_sig.c

This is not really required, but will assure that, from the perspective of
freebsd-update, the system will be entirely unchanged. There is simply no
impact on future updates as there are no changes left.


 I have had a hard time with freebsd-update when upgrading 10.0-RELEASE
 - 10.1-RELEASE:

 https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094
 and I do not want to get even more trouble letting
 freebsd-update confuse my system with a mixture of GENERIC and custom
 kernels ending in a situation where none of them is able to boot.

 I have learned that I can advice freebsd-update to not update my kernel
 but am still confused whether it is the version under /boot/GENERIC or
 the one under /boot/kernel. And I would like to know how to tell
 FreeBSD how to boot a certain kernel. All I know so far is that if a
 kernel fails to boot you have to boot into recovery and move kernel.old
 to kernel. Is there a boot menu available with the FreeBSD boot loader
 which would simplify life a lot?


The running kernel is in boot/kernel. /boot/GENERIC is not present unless
you create it and, when present, it is used as the kernel which
frebsd-update will patch in the upgrade phase and then install in the
install phase. Actually, the Handbook recommends always keeping a copy of
the GENERIC kernel as /boot/GENERIC. There is no reason not to allow

Re: www/squid does not shutdown via rc

2015-01-28 Thread Dr. Peter Voigt 
On Tue, 27 Jan 2015 11:51:51 +0100
Marko Cupać marko.cu...@mimar.rs wrote:

 On Tue, 27 Jan 2015 07:11:10 +
 Matthew Seaman matt...@freebsd.org wrote:
 
  On 2015/01/27 03:52, Kurt Jaeger wrote:
   Doesn't installing a custom kernel break freebsd-update ?
  
  No.  freebsd-update has always supported using a custom kernel.  It
  helps if you name your kernel something other than GENERIC, which
  you do by creating a modofoed kernel config file
  in /usr/src/sys/amd64/conf (or i386 if that's your architecture):
  eg.
  
  % cat FOO
  include GENERIC
  
  ident FOO
  
  and then add:
  
  KERNCONF=   FOO
  
  to /etc/make.conf
  
  You should also edit /etc/freebsd-update.conf and change the
  'Components' line to remove 'kernel' from the list.
  
  None of this is absolutely necessary, but it will help you avoid
  accidentally ending up with the generic kernel.
  
  In any case, what you will need to do is rebuild your kernel and
  reinstall it any time freebsd-update touches the kernel.  You can
  use freebsd-update to maintain the kernel sources, which will pull
  in the needed updates to the kernel sources.
 
 The timing for this is really unfortunate for me, because I have just
 re-installed my FreeBSD fleet of some 20 virtual servers without
 sources included, and I just introduced binary only policy (ok I do
 build my own ports on one server in poudriere, but all other servers
 use packages).
 
 I guess theoretically it is possible to make kernel build server
 which will build custom kernel for distribution to other servers. I
 am just not sure how will RELEASE userland tolerate STABLE kernel.
 
 Does this sound reasonable? Any tips?
 
 Thank you in advance,

Thanks to all who contributed to this thread.

@Kevin:
Your outline of kernel patching procedure is helpful and corresponds
in most aspects what I have thought so far. I aggree with you that
patching, building and installing a custom kernel can be managed. And I
am sure that I can do it.

So getting a custom kernel installed is one thing but keeping your
system in a manageable way is another. Kurt and Mattew pointed out that
you want to keep freebsd-update working in a reliable way and this
obviously needs some manual interaction. Information about it is
not too easily gathered and answers given here still leave some
question open to me.

I have had a hard time with freebsd-update when upgrading 10.0-RELEASE
- 10.1-RELEASE:  
https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094
and I do not want to get even more trouble letting
freebsd-update confuse my system with a mixture of GENERIC and custom
kernels ending in a situation where none of them is able to boot.

I have learned that I can advice freebsd-update to not update my kernel
but am still confused whether it is the version under /boot/GENERIC or
the one under /boot/kernel. And I would like to know how to tell
FreeBSD how to boot a certain kernel. All I know so far is that if a
kernel fails to boot you have to boot into recovery and move kernel.old
to kernel. Is there a boot menu available with the FreeBSD boot loader
which would simplify life a lot?

Furthermore, installing a custom kernel influcences a subsequent build
world process in  a way that I do not yet fully understand.

If all above is clarified I could go the way of using a custom kernel.
But to be honest: I would do it only, because I have just one
FreeBSD server to mannage this way. The other FreeBSD based servers
have FreeNAS and pfSense and are managed differently. But if I was an
administrator with several FreeBSD servers, this would not be a way to
go. 

Regards,
Peter
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-27 Thread Matthew Seaman 
On 2015/01/27 10:51, Marko Cupać wrote:
 I guess theoretically it is possible to make kernel build server which
 will build custom kernel for distribution to other servers. I am just
 not sure how will RELEASE userland tolerate STABLE kernel.

You can use the 10.1-RELEASE sources and apply the two patches manually
to ensure you have a compatible kernel.

Cheers,

Matthew
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-27 Thread Marko Cupać 
On Tue, 27 Jan 2015 07:11:10 +
Matthew Seaman matt...@freebsd.org wrote:

 On 2015/01/27 03:52, Kurt Jaeger wrote:
  Doesn't installing a custom kernel break freebsd-update ?
 
 No.  freebsd-update has always supported using a custom kernel.  It
 helps if you name your kernel something other than GENERIC, which you do
 by creating a modofoed kernel config file in /usr/src/sys/amd64/conf (or
 i386 if that's your architecture): eg.
 
 % cat FOO
 include GENERIC
 
 ident FOO
 
 and then add:
 
 KERNCONF= FOO
 
 to /etc/make.conf
 
 You should also edit /etc/freebsd-update.conf and change the
 'Components' line to remove 'kernel' from the list.
 
 None of this is absolutely necessary, but it will help you avoid
 accidentally ending up with the generic kernel.
 
 In any case, what you will need to do is rebuild your kernel and
 reinstall it any time freebsd-update touches the kernel.  You can use
 freebsd-update to maintain the kernel sources, which will pull in the
 needed updates to the kernel sources.

The timing for this is really unfortunate for me, because I have just
re-installed my FreeBSD fleet of some 20 virtual servers without sources
included, and I just introduced binary only policy (ok I do build my
own ports on one server in poudriere, but all other servers use packages).

I guess theoretically it is possible to make kernel build server which
will build custom kernel for distribution to other servers. I am just
not sure how will RELEASE userland tolerate STABLE kernel.

Does this sound reasonable? Any tips?

Thank you in advance,
-- 
Marko Cupać
https://www.mimar.rs
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

www/squid does not shutdown via rc

2015-01-26 Thread Marko Cupać 
Hi,

I am building new proxy server based on FreeBSD 10.1-RELEASE and latest
squid from ports (squid-3.4.11).

Squid starts and works ok when testing from single client, but it does
not shutdown correctly through rc script.

Starting situation: squid is not started, no pid dir and file in /var/run,
ps ax shows nothing related to squid.

Next: squid is started with 'service squid start', pid dir and file are
created in /var/run, 'service squid status' shows the same value as
pidfile:

% sudo service squid status
squid is running as pid 770.

% sudo cat /var/run/squid/squid.pid 
770

% ps waux | grep squid
squid  768   0.0  1.0 62096 10488  -  Is3:14PM  0:00.00 
/usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf
squid  770   0.0  1.8 82948 18764  -  S 3:14PM  0:00.36 (squid-1) -f 
/usr/local/etc/squid/squid.conf (squid)
squid  772   0.0  0.3 23876  3012  -  I 3:14PM  0:00.01 (logfile-daemon) 
/squid/logs/access.log (log_file_daemon)
squid  773   0.0  0.3 23872  3000  -  I 3:14PM  0:00.01 (unlinkd) (unlinkd)
squid  774   0.0  0.3 24256  3024  -  S 3:14PM  0:00.01 diskd 788484 788485 
788486

The problem arises when trying to stop squid:

% sudo service squid stop
Stopping squid.
Waiting for PIDS: 770.

Let's see if rc script finds it running:
% sudo service squid status
squid is not running.

There is no pid dir and file in /var/run/

However, ps shows running proceses:
squid  768   0.0  1.0 62096 10488  -  Is3:14PM  0:00.00 
/usr/local/sbin/squid -f /usr/local/etc/squid/squid.conf
squid  806   0.0  1.8 82948 18764  -  S 3:18PM  0:00.21 (squid-1) -f 
/usr/local/etc/squid/squid.conf (squid)
squid  807   0.0  0.3 23876  3012  -  I 3:18PM  0:00.01 (logfile-daemon) 
/squid/logs/access.log (log_file_daemon)
squid  808   0.0  0.3 23872  3000  -  I 3:18PM  0:00.01 (unlinkd) (unlinkd)
squid  809   0.0  0.3 24256  3024  -  S 3:18PM  0:00.01 diskd 825348 825349 
825350

Those are probably relevant:

from messages:
Jan 26 15:10:09 rsbgyucnix02 squid[558]: Squid Parent: (squid-1) process 560 
exited due to signal 6 with status 0
Jan 26 15:10:09 rsbgyucnix02 kernel: pid 560 (squid), uid 100: exited on signal 
6 (core dumped)
Jan 26 15:10:12 rsbgyucnix02 squid[558]: Squid Parent: (squid-1) process 733 
started
Jan 26 15:12:44 rsbgyucnix02 kernel: pid 733 (squid), uid 100: exited on signal 
6 (core dumped)
Jan 26 15:14:41 rsbgyucnix02 squid[768]: Squid Parent: will start 1 kids
Jan 26 15:14:41 rsbgyucnix02 squid[768]: Squid Parent: (squid-1) process 770 
started
Jan 26 15:18:18 rsbgyucnix02 squid[768]: Squid Parent: (squid-1) process 770 
exited due to signal 6 with status 0
Jan 26 15:18:18 rsbgyucnix02 kernel: pid 770 (squid), uid 100: exited on signal 
6 (core dumped)
Jan 26 15:18:22 rsbgyucnix02 squid[768]: Squid Parent: (squid-1) process 806 
started

from cache.log:
2015/01/26 15:14:43 kid1| storeLateRelease: released 0 objects
2015/01/26 15:18:18| Set Current Directory to /squid/cache
FATAL: Received Segment Violation...dying.
2015/01/26 15:18:18 kid1| Closing HTTP port 127.0.0.1:3128
2015/01/26 15:18:18 kid1| Closing HTTP port 10.20.0.12:8080
2015/01/26 15:18:18 kid1| storeDirWriteCleanLogs: Starting...

Could it be that I am doing something wrong or is this a bug?
-- 
Marko Cupać
https://www.mimar.rs
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Yasuhiro KIMURA 
From: Marko Cupać marko.cu...@mimar.rs
Subject: www/squid does not shutdown via rc
Date: Mon, 26 Jan 2015 15:24:33 +0100

 Could it be that I am doing something wrong or is this a bug?

Yes, this is bug. But it is bug of 10.1-RELEASE rather than squid.
See following bug report:

Bug 195802 - www/squid restarts after shutdown and dumps core
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195802

I applied 2 fixes to source tree of 10.1-RELEASE and rebuilt
kernel. Now squid shutdowns correctly.

---
Yasuhiro KIMURA
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Matthew Seaman 
On 01/26/15 16:05, Yasuhiro KIMURA wrote:
 https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_sig.c?view=patchr1=275456r2=275455pathrev=275456
 https://svnweb.freebsd.org/base/stable/10/sys/kern/kern_sig.c?view=patchr1=275502r2=275501pathrev=275502
 
 As URLs suggest, they are patch for stable/10. but can be applied to
 source of 10.1-RELEASE if you select proper combination of current
 directory and -p N option of patch(1).
 
  Also, is there a chance they will be pushed to freebsd-update?

No.  Unless these are either security fixes or fixes for a major
regression (which this is not) in 10.1-RELEASE, then they won't be
applied to that branch.

They will, however, be in the next release cut from stable/10, which
will be 10.2-RELEASE, and presumably in releases from other branches
from now on.

Your best recourse at the moment is to manually patch the kernel sources
and build yourself a custom kernel on the affected machines.

Cheers,

Matthew






signature.asc
Description: OpenPGP digital signature

Re: www/squid does not shutdown via rc

2015-01-26 Thread Marko Cupać 
On Tue, 27 Jan 2015 00:29:19 +0900 (JST)
Yasuhiro KIMURA y...@utahime.org wrote:

 From: Marko Cupać marko.cu...@mimar.rs
 Subject: www/squid does not shutdown via rc
 Date: Mon, 26 Jan 2015 15:24:33 +0100
 
  Could it be that I am doing something wrong or is this a bug?
 
 Yes, this is bug. But it is bug of 10.1-RELEASE rather than squid.
 See following bug report:
 
 Bug 195802 - www/squid restarts after shutdown and dumps core
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195802
 
 I applied 2 fixes to source tree of 10.1-RELEASE and rebuilt
 kernel. Now squid shutdowns correctly.

Hi Yasuhiro,

Thank you for your reply. Where can those fixes be found?

Also, is there a chance they will be pushed to freebsd-update?

I would be glad to do some testing on test server, but for production
servers I use binary updates only (freebsd-update). My servers are
on 10.1-RELEASE-p4 right now.

Regards,
-- 
Marko Cupać
https://www.mimar.rs
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Marko Cupać 
On Mon, 26 Jan 2015 16:20:46 +
Matthew Seaman matt...@freebsd.org wrote:

   Also, is there a chance they will be pushed to freebsd-update?
 
 No.  Unless these are either security fixes or fixes for a major
 regression (which this is not) in 10.1-RELEASE, then they won't be
 applied to that branch.

From OS point of view, this could be indeed seen as minor regression.

But please consider server admin's point of view:
- squid33 had latest release on 2014-08-27
- squid33 has been scheduled for expiration on 2015-01-31, but was
  extended to 2015-05-31 because of ntlm_auth issue in squid34
- squid34 does not run on 10.1-RELEASE-pX
- 10.2-RELEASE is not likely to be before 2015-05-31

Which means that pkg installs of latest squid (www/squid34) will be
useless on latest FreeBSD release (10.1-RELEASE) for a long time.

 They will, however, be in the next release cut from stable/10, which
 will be 10.2-RELEASE, and presumably in releases from other branches
 from now on.
 
 Your best recourse at the moment is to manually patch the kernel sources
 and build yourself a custom kernel on the affected machines.

I was looking forward to avoid it. Perhaps I'm succumbing to conformism.
-- 
Marko Cupać
https://www.mimar.rs
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Kevin Oberman 
On Mon, Jan 26, 2015 at 7:52 PM, Kurt Jaeger li...@opsec.eu wrote:

 Hi!

  As far as patching, it is really pretty easy and requires no special
 skills
  or knowledge.
 
  1. Download the two patches as ~/A.patch and ~/B.patch
 [...]

 Doesn't installing a custom kernel break freebsd-update ?

 --
 p...@opsec.eu+49 171 3101372 5 years to
 go !


Michelle,

Seriously? Yes. That is why I offered exact commands to enter. And I am not
a developer. My C skills are poor and I last wrote kernel code for VMS. I
am a system admin, either full or part time for at least 35 years, though,
so I am more comfortable than the average user. But the average user is not
installing and configuring squid, either.

It's a simple process and, as always when a new kernel is installed, the
old one is saved, so recovery is pretty easy. If someone looks at those
step and feels they are beyond, they won't so them, but right now they are
stuck. I have no influence with those who can decide when an update should
be made but I've been around FreeBSD long enough to know how unlikely it is
that an update to fix this is, so I am offering another option.

Kurt,

No. That is the purpose of copying the standard kernel to /boot/GENERIC is
for that purpose. It's not in the man pages but is in the Handbook. If you
have /boot/GENERIC, freebsd-update will use that kernel instead of
/boot/kernel/kernel. If you are making changes to the kernel of a release,
just be sure that you have copied the running kernel to /boot/GENERIC and
you are safe. (Of course, any changes to the kernel will be lost when
freebsd-update is run in the future, but in this case STABLE already has
the patches, so they (or something similar) will be in 10.2.

The only problem is a security patch that updates the kernel. After that,
the patches would have to be re-applied, the new kernel copied to
/boot/GENERIC and so on.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Matthew Seaman 
On 2015/01/27 03:52, Kurt Jaeger wrote:
 Doesn't installing a custom kernel break freebsd-update ?

No.  freebsd-update has always supported using a custom kernel.  It
helps if you name your kernel something other than GENERIC, which you do
by creating a modofoed kernel config file in /usr/src/sys/amd64/conf (or
i386 if that's your architecture): eg.

% cat FOO
include GENERIC

ident FOO

and then add:

KERNCONF=   FOO

to /etc/make.conf

You should also edit /etc/freebsd-update.conf and change the
'Components' line to remove 'kernel' from the list.

None of this is absolutely necessary, but it will help you avoid
accidentally ending up with the generic kernel.

In any case, what you will need to do is rebuild your kernel and
reinstall it any time freebsd-update touches the kernel.  You can use
freebsd-update to maintain the kernel sources, which will pull in the
needed updates to the kernel sources.

Cheers,

Matthew





___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Kurt Jaeger 
Hi!

 As far as patching, it is really pretty easy and requires no special skills
 or knowledge.
 
 1. Download the two patches as ~/A.patch and ~/B.patch
[...]

Doesn't installing a custom kernel break freebsd-update ?

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Michelle Sullivan 
Kevin Oberman wrote:
 On Mon, Jan 26, 2015 at 2:56 PM, Dr. Peter Voigt pvo...@uos.de wrote:

   
 On Mon, 26 Jan 2015 21:25:14 +0100
 Marko Cupać marko.cu...@mimar.rs wrote:

 
 On Mon, 26 Jan 2015 16:20:46 +
 Matthew Seaman matt...@freebsd.org wrote:

   
 Also, is there a chance they will be pushed to freebsd-update?
   
 No.  Unless these are either security fixes or fixes for a major
 regression (which this is not) in 10.1-RELEASE, then they won't be
 applied to that branch.
 
 From OS point of view, this could be indeed seen as minor regression.

 But please consider server admin's point of view:
 - squid33 had latest release on 2014-08-27
 - squid33 has been scheduled for expiration on 2015-01-31, but was
   extended to 2015-05-31 because of ntlm_auth issue in squid34
 - squid34 does not run on 10.1-RELEASE-pX
 - 10.2-RELEASE is not likely to be before 2015-05-31

 Which means that pkg installs of latest squid (www/squid34) will be
 useless on latest FreeBSD release (10.1-RELEASE) for a long time.

   
 They will, however, be in the next release cut from stable/10, which
 will be 10.2-RELEASE, and presumably in releases from other branches
 from now on.

 Your best recourse at the moment is to manually patch the kernel
 sources and build yourself a custom kernel on the affected machines.
 
 I was looking forward to avoid it. Perhaps I'm succumbing to
 conformism.
   
 I am suffering from the same 10.1/Squid problem for some time and I am
 glad stumbling across this thread. Fortunately Squid is running stable
 apart from this shutdown issue.

 To me it looks like a serious kernel issue and I can hardly believe it
 will not be fixed in the 10.1-RELEASE.

 It is quite an effort to compile, manually patch and install a custom
 kernel, if you aren't too experienced like I am. I have only managed
 building the GENERIC kernel so far as part of the build world process
 when upgrading to 10.1.

 While I can sympathize with those hitting this  bug, shortly after a
 
 release FreeBSD support is turned over to the Security Officer and it is
 very difficult to get it pulled back. The fear that a change will break
 other stuff is too great, so it's very unlikely to happen for anything that
 is not:
 1) A security issue
 2) Causes the base system to have serious stability issues

 Painful as this may be to squid users, it is just not at the level a a
 release re-roll.

 As far as patching, it is really pretty easy and requires no special skills
 or knowledge.

 1. Download the two patches as ~/A.patch and ~/B.patch
 2. Apply them to the source
 # cd /usr/src
 # patch -p2  ~/A.patch
 # patch -p2  ~/B.patch
 3. Save your existing kernel for future updates (security patches or 10.2)
 # cp /boot/kernel/kernel /boot/GENERIC
 4. Rebuild the kernel
 # make buildkernel (If you have multiple cores, the kernel will build
 much faster if you add he '-jN' option where 'N' is 1 or two more than the
 number of cores)
 5. Install the new kernel
 # make installkernel
 6. Reboot to start the new kernel

   
Seriously Kevin?

(and by that I know it's only 6 'easy' steps, however you seem (like
other) to be forgetting...  FreeBSD Users are not FreeBSD developers!)

-- 
Michelle Sullivan
http://www.mhix.org/

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Dr. Peter Voigt 
On Mon, 26 Jan 2015 21:25:14 +0100
Marko Cupać marko.cu...@mimar.rs wrote:

 On Mon, 26 Jan 2015 16:20:46 +
 Matthew Seaman matt...@freebsd.org wrote:
 
Also, is there a chance they will be pushed to freebsd-update?
  
  No.  Unless these are either security fixes or fixes for a major
  regression (which this is not) in 10.1-RELEASE, then they won't be
  applied to that branch.
 
 From OS point of view, this could be indeed seen as minor regression.
 
 But please consider server admin's point of view:
 - squid33 had latest release on 2014-08-27
 - squid33 has been scheduled for expiration on 2015-01-31, but was
   extended to 2015-05-31 because of ntlm_auth issue in squid34
 - squid34 does not run on 10.1-RELEASE-pX
 - 10.2-RELEASE is not likely to be before 2015-05-31
 
 Which means that pkg installs of latest squid (www/squid34) will be
 useless on latest FreeBSD release (10.1-RELEASE) for a long time.
 
  They will, however, be in the next release cut from stable/10, which
  will be 10.2-RELEASE, and presumably in releases from other branches
  from now on.
  
  Your best recourse at the moment is to manually patch the kernel
  sources and build yourself a custom kernel on the affected machines.
 
 I was looking forward to avoid it. Perhaps I'm succumbing to
 conformism.

I am suffering from the same 10.1/Squid problem for some time and I am
glad stumbling across this thread. Fortunately Squid is running stable
apart from this shutdown issue.

To me it looks like a serious kernel issue and I can hardly believe it
will not be fixed in the 10.1-RELEASE.

It is quite an effort to compile, manually patch and install a custom
kernel, if you aren't too experienced like I am. I have only managed
building the GENERIC kernel so far as part of the build world process
when upgrading to 10.1.

Regards,
Peter
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Nick Rogers 
On Mon, Jan 26, 2015 at 12:25 PM, Marko Cupać marko.cu...@mimar.rs wrote:

 On Mon, 26 Jan 2015 16:20:46 +
 Matthew Seaman matt...@freebsd.org wrote:

Also, is there a chance they will be pushed to freebsd-update?
 
  No.  Unless these are either security fixes or fixes for a major
  regression (which this is not) in 10.1-RELEASE, then they won't be
  applied to that branch.

 From OS point of view, this could be indeed seen as minor regression.

 But please consider server admin's point of view:
 - squid33 had latest release on 2014-08-27
 - squid33 has been scheduled for expiration on 2015-01-31, but was
   extended to 2015-05-31 because of ntlm_auth issue in squid34
 - squid34 does not run on 10.1-RELEASE-pX
 - 10.2-RELEASE is not likely to be before 2015-05-31

 Which means that pkg installs of latest squid (www/squid34) will be
 useless on latest FreeBSD release (10.1-RELEASE) for a long time.


I'm also now having to patch my 10.1-RELEASE kernel to get around this
problem. Sounds like a fairly serious regression to me as well, at least
for squid users.


  They will, however, be in the next release cut from stable/10, which
  will be 10.2-RELEASE, and presumably in releases from other branches
  from now on.
 
  Your best recourse at the moment is to manually patch the kernel sources
  and build yourself a custom kernel on the affected machines.

 I was looking forward to avoid it. Perhaps I'm succumbing to conformism.
 --
 Marko Cupać
 https://www.mimar.rs
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread Kevin Oberman 
On Mon, Jan 26, 2015 at 2:56 PM, Dr. Peter Voigt pvo...@uos.de wrote:

 On Mon, 26 Jan 2015 21:25:14 +0100
 Marko Cupać marko.cu...@mimar.rs wrote:

  On Mon, 26 Jan 2015 16:20:46 +
  Matthew Seaman matt...@freebsd.org wrote:
 
 Also, is there a chance they will be pushed to freebsd-update?
  
   No.  Unless these are either security fixes or fixes for a major
   regression (which this is not) in 10.1-RELEASE, then they won't be
   applied to that branch.
 
  From OS point of view, this could be indeed seen as minor regression.
 
  But please consider server admin's point of view:
  - squid33 had latest release on 2014-08-27
  - squid33 has been scheduled for expiration on 2015-01-31, but was
extended to 2015-05-31 because of ntlm_auth issue in squid34
  - squid34 does not run on 10.1-RELEASE-pX
  - 10.2-RELEASE is not likely to be before 2015-05-31
 
  Which means that pkg installs of latest squid (www/squid34) will be
  useless on latest FreeBSD release (10.1-RELEASE) for a long time.
 
   They will, however, be in the next release cut from stable/10, which
   will be 10.2-RELEASE, and presumably in releases from other branches
   from now on.
  
   Your best recourse at the moment is to manually patch the kernel
   sources and build yourself a custom kernel on the affected machines.
 
  I was looking forward to avoid it. Perhaps I'm succumbing to
  conformism.

 I am suffering from the same 10.1/Squid problem for some time and I am
 glad stumbling across this thread. Fortunately Squid is running stable
 apart from this shutdown issue.

 To me it looks like a serious kernel issue and I can hardly believe it
 will not be fixed in the 10.1-RELEASE.

 It is quite an effort to compile, manually patch and install a custom
 kernel, if you aren't too experienced like I am. I have only managed
 building the GENERIC kernel so far as part of the build world process
 when upgrading to 10.1.

 While I can sympathize with those hitting this  bug, shortly after a
release FreeBSD support is turned over to the Security Officer and it is
very difficult to get it pulled back. The fear that a change will break
other stuff is too great, so it's very unlikely to happen for anything that
is not:
1) A security issue
2) Causes the base system to have serious stability issues

Painful as this may be to squid users, it is just not at the level a a
release re-roll.

As far as patching, it is really pretty easy and requires no special skills
or knowledge.

1. Download the two patches as ~/A.patch and ~/B.patch
2. Apply them to the source
# cd /usr/src
# patch -p2  ~/A.patch
# patch -p2  ~/B.patch
3. Save your existing kernel for future updates (security patches or 10.2)
# cp /boot/kernel/kernel /boot/GENERIC
4. Rebuild the kernel
# make buildkernel (If you have multiple cores, the kernel will build
much faster if you add he '-jN' option where 'N' is 1 or two more than the
number of cores)
5. Install the new kernel
# make installkernel
6. Reboot to start the new kernel

If the new kernel doesn't work, the old kernel can be restored from
/boot/GENERIC or you can boot kernel.old.
--
Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

Re: www/squid does not shutdown via rc

2015-01-26 Thread John Marshall 
On Tue, 27 Jan 2015, 00:29 +0900, Yasuhiro KIMURA wrote:
 
 Yes, this is bug. But it is bug of 10.1-RELEASE rather than squid.
 See following bug report:
 
 Bug 195802 - www/squid restarts after shutdown and dumps core
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195802

Thank you so much for posting this link!  Merging r275456 and r275502
from stable/10 to my releng/10.1 src tree and rebuilding and installing
the kernel, means that I can once again manage squid 3.4.n via the rc.d
script instead of a prescribed series of kill(1) commands.

...and thank you rea@ and kib@ for the patches!

-- 
John Marshall


pgpaxZ1Xgs00w.pgp
Description: PGP signature