similar to: 2.0.5: problem with HUP reopening logs

rh60/2.2.10-ac10 Compiling utils/torture.c utils/torture.c: In function `run_browsetest': utils/torture.c:929: invalid type argument of `->' utils/torture.c:934: invalid type argument of `->' utils/torture.c: In function `create_procs': utils/torture.c:1118: warning: initialization discards `volatile' from pointer target type utils/torture.c:1118: warning: passing arg 1

The 2.04b rpm for rh60 ships with and installs a config file for logrotate (the samba.log file in the packaging/RedHat section). ===== /var/log/samba/log.nmb { postrotate /usr/bin/killall -HUP nmbd endrotate } /var/log/samba/log.smb { postrotate /usr/bin/killall -HUP smbd endrotate } ===== 1) I think that the use of "endrotate" is wrong. There is no

Hi, I thought that HUPing the master smbd process (and/or the child processes) was supposed to cause the logfiles to be reopened? This does not appear to happen on our installation (2.0.4b2, Solaris 2.6). If I make a connection to a share, rename the logfile and HUP/delete the daemon (either parent or child), a new file is not created. Alternatively, how about a feature where we can signal

Since the release of the first 2.0.x (jan1999) I noted that smbclient '\\server\share' -Tx filename.tar was terribly slow. smbclient '\\server\share' -Tc filename.tar is as fast as 1.9.18. If I use smbclient from 1.9.18 the performance is high (with the same target pc). These are some tests with: - Win98pc - lan 10Mbps - samba-2.0.5-pre4/rh60 - a dir containing 1,2MB in 52

independent from Configuration Reload In-Reply-To: <200406161051.03808.msmith@xiph.org> References: <1087307353.28637.11.camel@forge.intermeta.de> <200406161051.03808.msmith@xiph.org> Message-ID: <1087392799.7778.4.camel@forge.intermeta.de> Hi, yes, I tested the patch. Then I sent you the wrong version. I attached the correct one. Yes, this one works. Why just reopening

This is the list of problems I had with samba-2.0.6 so far. Can anyone tell me if he can reproduce them and if he considers them as problems? 2.0.6 on linux 2.2.13 or 2.0.33 1) sighup/log reopening doesn't always work: connections that are already active keep logging to the old logs; logrotate rotates/zip the logs and samba stops logging completely till restart. 2) Localized chars. I have

2.0.5 (on linux) has a small annoyance in that, when the log files get rotated, kill -HUP won't point the daemons to the new log files. They keeps logging to the old ones until they are stopped/started. Does 2.0.6 fix this?

Many 2.0.x users have the: [1999/06/23 10:47:48, 0] smbd/oplock.c:oplock_break(773) oplock_break resend [1999/06/23 10:47:58, 0] smbd/oplock.c:oplock_break(773) oplock_break resend [1999/06/23 10:48:08, 0] smbd/oplock.c:oplock_break(773) oplock_break resend [1999/06/23 10:48:18, 0] smbd/oplock.c:oplock_break(790) oplock_break: receive_smb timed out after 30 seconds. problem. I get this

I''ve been tinkering around with managing users and am concerned with the overall administrative usability of the inheritance overrides. For instance, the user games: redhat_base: user { games: ensure => present } local_site inherits redhat_base: User[games] { ensure => absent } This is fine, but imagine a few levels of nesting later with an admin that wants to ensure that a

Hai, Im wondering here.. If the client is a windows 10 pc connecting, > ../source3/smbd/negprot.c:419(reply_nt1) using SPNEGO > ../source3/smbd/negprot.c:761(reply_negprot) Selected protocol NT LM 0.12 > ../source3/smbd/process.c:554(receive_smb_talloc) > receive_smb_raw_talloc failed for client > ipv4:10.55.66.82:59271 read error = NT_STATUS_CONNECTION_RESET. And i

Hi, I need to re-open the thread blow. The situation is still the same. The HUP signal does not trigger reloading of subnet declarations in own hosts file (Version 1.0.35). After a quick view to the source code, file src/net.c shows in line 658 would reload subnets when using StrictSubnets only. But why? With StrictSubnets it doesn't make sense to me. I did a quick check and removed the if

Currently, on deploys we''re sending HUP to the "old" master to reload the config, and then we send it a USR2 to reload the app code. Is this redundant -- i.e. does USR2 reload the unicorn config, or just the application code? I am under the impression that USR2 forks a new master from the old, and only reloads app code, and not the unicorn config, but I just wanted to double

I''ve been going through Pat''s example story and noticed that there was no checking for a bad login. I assume this is because that would have made the article bigger and more complicated than it needed to be. So the question that comes of of this is: How do folks normally handle the negative case? My plan was to just use another scenario, but as a new person to BDD/TDD,

With the latest version of Mongrel, will Mongrel reopen log files when sent a HUP signal? I would like to do a log rotate, but would prefer not to restart the mongrel instances as monit is watching after them all. monit is great for restarting the individual instances, but I would prefer not to do a restart all through monit. I would be curious if this is advisable. -- ----- Christopher

Hi folks, I''ve experimented a problem while deploying my app, I''ve sent the HUP signal to the master process, I''ve checked everything is ok: new master and workers are spawned and the old ones are killed(I''ve checked the PIDs), but the new code deployed isn''t reflected in the living site, so I''ve to stop and start again unicorn in order to see

Noticed the following on the CLI: Received HUP signal -- Reloading configs == Parsing '/etc/asterisk/extconfig.conf': Found == Parsing '/etc/asterisk/manager.conf': Found <snip> How do I track down the source of the HUP? There are no indications in any log files and I do not have any cron entries for * (RHv9). Is asterisk doing this for some reason via internal

Hi: I noticed in an icecast2 log that a HUP will reload the server config. This is a nice feature. Are there any configuration options that won't take effect with such a reload, or will it completely take effect? If the ports have changed, for example, will these change? Geoff. <p> -- Geoff Shang <gshang@uq.net.au> ICQ number 43634701 Make sure your E-mail can be read by

Hi, If sshd is started with 'sshd', restarting with kill -HUP will fail. I've included the most obvious patch, but making sure that the full pathname is in saved_argv[0] just might be more secure. Cheers, Han Holl --- sshd.c.orig Mon Feb 19 10:55:54 2001 +++ sshd.c Mon Feb 19 10:56:15 2001 @@ -208,7 +208,7 @@ { log("Received SIGHUP; restarting.");

I have this strange problem where when I try to reload my config by sending a HUP to the icecast process it produces this in the error.log file: [2004-01-15 21:06:07] INFO connection/connection_accept_loop Scheduling config reread ... [2004-01-15 21:06:07] EROR event/event_config_read Error parsing config, not replacing existing config [2004-01-15 21:06:07] EROR event/event_config_read Parse

Hello I'm running CentOS 5.3 with httpd-2.2.3-22.el5.centos.x86_64 and php-5.1.6-23.2.el5_3.x86_64. When the logrotate scripts run and send the HUP signal to httpd, the httpd process quits instead of reloading. The only thing I can find in the logs is this: [Sun Apr 19 04:02:04 2009] [notice] seg fault or similar nasty error detected in the parent process There wasn't any segfault