search for: sighuped

From: Simon Perreault <nomis80 at lqt.ca> > Sure, theoretically it would be possible, but how would you restart this one? > [nomis80 at poste10-153 ~]$ sudo lsof | grep libc | grep init > init 1 root mem REG 253,0 1521500 999437 /lib/tls/libc-2.3.5.so I need to verify the post-install script for the glibc RPM, but I believe it SIGHUPs the process -- and

Why does cpanel want to remove ices files? How can I prevent this from occurring? What I get is /libexec/ld-elf.so.1: Shared object "libshout.so.3" not found, required by "ices" after cpanel does it nightly updates. Also if I do a SIGHUP to ices to update a playlist, do I just need to issue the command ices SIGHUP? What would be the correct format. Again, I apologize for

https://bugzilla.mindrot.org/show_bug.cgi?id=1692 Summary: sshd sometimes dies when sent multiple SIGHUPs in quick succession Product: Portable OpenSSH Version: 5.3p1 Platform: Other URL: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug /497781 OS/Version: Linux Status: NEW

I have the sshd daemon located at /sbin/ssh_22 in this scenario (because I have more than one daemon with separate executable images). After upgrading from 3.6.1p2 to 3.7p1, with the /sbin/ssh_22 copy replaced by mv (not by writing over the existing image), I do SIGHUP and get this message logged: Sep 16 15:07:36 vega sshd_22[22552]: Received SIGHUP; restarting. Sep 16 15:07:36 vega

Hi Is it possible to send SIGHUP to the parant process to let samba reread the smb.conf file, or is any way to let samba reread this file without restarting samba regards Alaa

On 29 July 2014 15:02, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > You mean replacing SIGUSR1 with SIGHUP in the test case? Weird, I > don't see how they are different. So, AFAIK, they should be identical. But I put some printfs and sleeps around and it wasn't a synchronization issue. My man page says that SIGUSR1 should terminate if there isn't a handler for

Dear All: --- Summary, especially for openssh list (to test/reproduce): THANK YOU for all your help. Please extract into /home/username/nx on both host and client. cp ssh to a file named mxssh in that directory. Run (with an _n_ below) Start server on the remote host by typing ./server & Now do: ./nxssh hostname If you killall client on the remote end, it reconnects "seamlessly"

I can. I've removed every other compilation flags from clang and even used GCC, with the exact same behaviour. cheers, --renato On 29 July 2014 15:15, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > OK, we can switch to SIGHUP. Could you please verify that this SIGUSR1 > behavior is not caused by MSan? > > On Tue, Jul 29, 2014 at 6:09 PM, Renato Golin

The stub domain device model needs to trap the termination signal so as to actually destroy the stub domain. SIGKILL can''t be trapped, SIGTERM is caught by SDL and so may be unnoticed. SIGHUP can be trapped and is not caught by SDL (and by default causes a process termination without core). Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r 2407a61c0d30

running 2.05a on red hat 6.1 I get a lot of these in my logs: smbd/process.c:timeout_processing(868) Reloading services after SIGHUP. Can anyone shed any light on this?

Hello, OpenSSH 2.5.1p1 running under AIX 4.3.3ML06. When I send a HUP signal to the parent sshd, that parent process dies, it's children get "adopted" by init, and the following message is put in the error log ... Mar 13 12:01:48 whippet sshd[31644]: Received SIGHUP; restarting. Mar 13 12:01:48 whippet sshd[31644]: RESTART FAILED: av[0]='sshd', error: No such file or

That doesn’t work too. :-( Last login: Mon Mar 19 19:18:16 on console iMac:~ andre$ mount /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) /dev/disk2 on /Volumes/G-DRIVE Thunderbolt 3 (hfs, local, nodev, nosuid, journaled, noowners) iMac:~ andre$

Hi, I search in archive list if there any reason why is removed in openssh newer than 2.9.9 from function 'void session_close_by_channel(int id, void *arg)' sending of SIGTEMR and SIGHUP signals to child as was in 2.9.9 version? See follow sniped code from 2.9.9 sources: ---- openssh-2.9.9/session.c ---------------------------------------- void session_close_by_channel(int id, void

Hello people This is on OpenBSD/sparc64. After chickening along with 0.99 for a while, I finally upgraded to 1.0-test. I started out with test73, which worked fine. With the upgrade to test76, I lost the ability to SIGHUP dovecot when I rotated it's logfile. Dovecot would just die abruptly, not a trace in the log. I just upgraded to test77, but the problem is still there. I've put

Hello, I noticed some random crashes after sending SIGHUP to the daemon (especially when some connections are continually failling). Playing around with gdb, it seems that after SIGHUP, all the "outgoing" information of the connections is being cleared, but later on it is being used in other places while still equal to NULL. The attached patch tries to fix this by avoiding these

Just started building the new network with automatic updates and noticed a very weird thing: when master tincd was reloaded (which sends updates), it stopped sending updates. Debugging session revealed that lookup_config(config_tree, NAME) returned NULL when NAME was any configuration item from our host file _after_ SIGHUP. Before it, it returned valid value. I see config_tree is appended with

What is the order that rsync uses to set permissions? Time Machine directories have ACL permissions that basically prohibit making any changes of any kind. In order to make a backup of the directory, you would need to set those permissions after copying everything in the subdirectories. Is rsync smart enough to do it in that order? On 2018-03-19, at 10:44 PM, Andre Althoff via rsync <rsync

Hello, the manpage of ices0 states that on SIGHUP, it'll reopen config and playlist. However, if I change the playlist and HUP, it seems it's still using the old one. Is this expected beharviour and I'm just missing something? Thanks for any insight, Frank

Anybody else seen this one? We're running Dovecot 1.0.rc7 on a different port on our live server (we're generally live with 1.0.beta5) and after a HUP to reload the user database (in a passwd-file) this morning we got:- > dovecot: Sep 22 07:45:05 Info: IMAP 14482 someuser xxx.xxx.xxx.xxx : Disconnected in IDLE > dovecot: Sep 22 07:45:05 Warning: imap-login: SSL_read() syscall

I have a script that normally runs my snapshot that I haven't used for the past several days because something seemed to be going wrong and I wanted to run things manually. But running the script twice today, I got: > snaphome Found 15 mounted dated, snaps or snap archives ?[snapper#2120]base_mp=/home 1 snap dated today. (Use: '--force=force_create_snap' to force another snap.)