Re: Questions about SIGHUP behavior
On 11/12/2013 07:35 AM, Steffen Dettmer wrote: Debian 7.2 with /bin/bash as login shell (via /etc/passwd), shopt huponexit off (as by default), bash run via SSH from other host. When closing shell with CTRL-D, "sleep &" continues to run. I had expected I had to use nohup, setsid, disown or a combination of them in order to keep background jobs running after ending a shell session. Short answer: I doubt that this ever worked as you think it did; if you're using a shell with job control and run programs in the background, the shell needs to deliver the HUP signal, which can happen in one of two ways in bash: huponexit on; or SIGHUP delivered to bash. Long answer: SIGHUP is not necessarily sent by the shell to background processes when it exits, but more often by the controlling tty's driver or line discipline, which on most Unixes (Linux included) is sadly a morass of cruft with multiple APIs that evolved separately and later merged. Back in the bad old days, when one used a "real" terminal on RS232 and turned off the terminal, or logged in via a modem connected to the system via RS232 and "hung up" the phone, the DSR line would fall and both foreground and background processes would get SIGHUP (hang up) from the tty driver, because it was the "controlling tty" (a concept that still exists today even though real terminals are almost extinct). Keep in mind, unless one was using the C shell, this was before "job control". Fast-forward to today: bash by default uses job control except when executing a script, and in the case of SSH, a pseudo-tty is used to simulate the "real" device and its driver [details at pty(7)]. If you have a read of setpgid(2) [also of interest tty_ioctl(4)], you'll see that (basically) on hangup of the tty device a SIGHUP is delivered to the "foreground process group of the controlling terminal". Without defining the "foreground process group" too carefully, suffice it to say that processes can be put in or out of it via system calls like setpgid(2) by the shell, various "daemon starting" programs, or themselves. More important, we can easily see which processes are in it by looking at the pgid and tpgid columns of ps(1)'s output. For the final piece of the puzzle, check the relevant section of bash(1): "The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs [...] If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits." [An 'interactive' shell means (basically) one that is running on a tty rather than reading a script from a file.] A little investigation with ps will show see why your sleep process didn't receive a SIGHUP: when job control is enabled, bash moves background jobs out of the foreground process group; they therefore won't receive a SIGHUP from the tty driver, and since (a) you are exiting bash via EOF and (b) you don't have huponexit set, bash doesn't send it to them. Note that had bash exited due to receiving a SIGHUP *itself* (which would happen e.g. if sshd died and released the pty), it would have delivered the SIGHUP to all of its jobs, foreground and background, which is one reason why you want to use commands like nohup, disown, etc. if you want to really be sure that your background commands continue to run even after you logout. The following session log demonstrates all of this. I use 'sleep 1h' and 'sleep 2h' to make clearer in the output of 'ps' which command was run by 'nohup' (but notice also the 'ignored' column). ~ % # ===> ~ % # ===> First, let's run some commands in the background with job-control enabled. ~ % # ===> ~ % ssh localhost ... ~ % sleep 1h & [1] 32187 ~ % nohup sleep 2h & [2] 32204 ~ % nohup: ignoring input and appending output to `nohup.out' ~ % ps -o pid,ppid,pgid,sess,tpgid,tty,ignored,args PID PPID PGID SESS TPGID TT IGNORED COMMAND 31723 31722 31723 31723 32281 pts/21 00384004 -bash 32187 31723 32187 31723 32281 pts/21 sleep 1h 32204 31723 32204 31723 32281 pts/21 0001 sleep 2h 32281 31723 32281 31723 32281 pts/21 ps -o pid,ppid, ~ % #Notice ^ that the jobs have different PGID's from bash and the TPGID. ~ % exit logout Connection to localhost closed. ~ % # Check that both 'sleep' processes are still running: ~ % ps -eo pid,ppid,pgid,sess,tpgid,tty,ignored,args |grep sleep |grep -v grep 32187 1 32187 31723-1 ? sleep 1h 32204 1 32204 31723-1 ? 0001 sleep 2h ~ % ~ % # Demonstrate the effects of nohup on one of them: ~ % kill -HUP 32187 32204 ~ % ps -eo pid,ppid,pgid,sess,tpgid,tty,ignored,args |grep sleep |grep -v grep 32204 1 32204 31723-1 ? 0001 sleep 2h ~ % ~ % # OK, now kill it too: ~ % kill -TERM 32204 ~ % ps -eo pid,ppid,pgid,sess,tpgid,tty,ignored,args |grep sleep |grep -v grep ~ % ~ % # ===> ~ % # ===> Try the same
How to start using a free OS (was: Why Debian)
On 11/10/2013 10:17 AM, thomas aylward wrote:
how does a novice begin with debian? Tom
I think there is some confusion that is introduced when we call a
distribution like Debian an "operating system," which used to be a term used
for the software that interacts with hardware, loads and runs other
software, controls basic resources, etc. Debian is a collection of
thousands of pieces of software, most of which are what used to be called
"applications" and would have been considered separate from the "operating
system" (1). There are good reasons for this, we all know that it makes a
lot of sense to have a common distribution and update system for the OS,
libraries, applications, all of the dependencies worked out and updates
coordinated; and that this is really only possible with free software.
The reason why I bring this up is that when a user tries to switch from a
proprietary OS to a free OS, the switching of the core operating system is
likely nearly invisible to them; but they often are also switching many of
the applications that they use every day, and this is where it becomes such
a difficult transition and a steep learning curve.
But, some (many?) of these free software applications can also run on
proprietary OSs (2). So, my advice to a novice who is using a proprietary
OS and wants to begin with Debian, or any other free OS, is to start by
using free software on their proprietary OS. Don't install an entire
operating system on a virtual machine, don't install a multi-boot system, I
think that without a _very_ motivated user, these efforts are usually
abandoned. A live image is OK just to take a look, but is usually
problematic to use as an ongoing every-day machine.
Instead, try using a free-software web-browser (Firefox & Chromium come to
mind as cross-platform choices). Step by step, try using free alternatives
to your main applications. I don't normally use proprietary OSs, so I don't
know for sure which software that runs on Debian also has portability to
proprietary OSs, but I think that LibreOffice, Thunderbird, Gimp, Pidgin all
have versions for the major proprietary OSs and I'm sure that many others do
as well. In many cases they may be far superior quality to the proprietary
applications that the user is used to. If you're a developer, start using
gcc or clang, and so forth. With each new application that is tried, give
it time to get familiar with it, find the edge cases, get fast at doing your
normal operations, so that when you try the next one, you don't mind the
extra time to figure out its workflow. Switching to booting directly into a
free OS should be the _last_ step, and if the user has already made the
transition so that he or she is already using 90% of the applications that
will be used in the new environment, it will be trivial and there is no need
for virtual machines or live-boot images.
By trying to make the entire transition in one fell swoop, it is _vastly_
more difficult. People need their computers to do real work for them. If
they are only trying to learn a new way to do one piece of the picture at
once, it's tolerable. If every step of the way it's a frustrating
experience due to lack of familiarity, the user will revert back to their
familiar environment in short order, 9 times out of 10, and that will be the
end of the experiment.
-- David
(1): Admittedly there is no perfect criterion to differentiate between OS
and application and I eschew the distinction anyhow [it reminds me of the
artificial distinction between "systems programming" and "applications
programming" which I also don't make -- to be a good programmer, you need
the same skills for both so there's no such thing as an "application
programmer"]. My point here is only that the usage of the term "Operating
System" has become much more expansive and ambiguous over the last several
decades -- although that trend started even earlier, e.g. with Unix's
separation of the shell from the supervisor program (kernel) and the
separation of the system commands ("ls", "ps") from the shell, leading to a
whole blurry spectrum of "system" and "application" programs.
(2): I remember when the entire "GNU system" (as it was called then) ran
essentially exclusively on top of proprietary OS's. You could buy it
mail-order from the FSF on 9-track mag tape and compile it on your
proprietary OS to get much improved versions of the standard Unix utilities
such as cc, tar, make, etc. as well as GNU-only stuff like emacs. I
initially adopted gcc mostly because it was almost the only way on my system
to get ANSI C rather than K&R. So, while I don't do it and always recommend
against it, I also don't let anyone tell me that there's something wrong or
immoral with running free software together with proprietary software --
they may not like to admit it, but they _all_ did it themselves at one time.
--
To UNSUBSCRIBE, email to debian-use
Re: IPTables question
On 11/09/2013 12:47 PM, Bill.M wrote: > But is there anyway to specify both eth0 and wlan0 as equally valid > interfaces on my laptop depending on whether it's in my dock or on the road? > > For example, -i wlan0,eth0 or -o wlan0,eth0 > Is something like these possible? * You can avoid specifying any interface at all, so long as you don't mind the rule being applied to the loopback interface as well. Chances are very good that this will work for you and is the best solution, but you need to evaluate the rules in question. * You can use a '+' at the end of the interface name which acts as a wildcard. This won't help since your interfaces names differ in the first character, not the last, but you can easily customize their names to differ in their suffix rather than prefix by editing: /etc/udev/rules.d/70-persistent-net.rules * You can create a new chain, have packets from either interface jump to it via two rules, then put the rest of your rules in that chain, without specifying an interface name. e.g. (untested): iptables -t filter -N foo iptables -t filter -A INPUT -i eth0 -j foo iptables -t filter -A INPUT -i wlan0 -j foo iptables -t filter -A foo --src 1.2.3.4 -j DROP iptables -t filter -A foo -p tcp --dport 80 -j DROP ... -- David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527e99f5.8070...@meta-dynamic.com
Re: ext3 mount failing due to bad superblock.
On 11/09/2013 04:09 AM, darkestkhan wrote:
> Funny thing (actually not so) - my optic drive is dead. But why do I
> have to reboot
> into recovery mode? System itself works correctly - /boot is on sda2
> and everything
> else is on LVM at sda3
If I understand you correctly that you can boot and use your system without
using the affected drive, then you don't need to boot from alternate media
to troubleshoot the filesystem; but I would still recommend it (can you boot
from a USB flash drive?). If you must boot from the installed distro, it
might be better to boot in single-user ("recovery") mode. The reason for
this is that most distributions are configured to automatically access
drives and filesystems, if only to probe them to determine what filesystems
are available. In general, when troubleshooting filesystems and hard
drives, it's best only to access them in a very controlled way. But please
consider using a live boot distribution that is specifically tailored for
this kind of work, such as parted magic, system rescue cd, etc.
You haven't given enough information, so it's hard to say for sure what is
the problem, forcing us to speculate heavily. You should definitely check
the SMART data on the drive (use smartmontools package) to determine the
status of the drive hardware. The output of dumpe2fs will be helpful. Also
check your _entire_ kernel log, looking for any ATA or other errors that
would indicate drive/controller failures, as well as filesystem messages.
Nonetheless, there are 3 main possibilities:
A. hardware failure: your drive is hosed; there are a number of
sub-possibilities here: controller, cable, drive's controller card, drive
platter surface, drive head, etc.
B. software failure: the drive is working fine but somehow the data on it
became corrupted, either due to a bug in the filesystem software, through a
user-induced error such as writing to /dev/sdX, system crash, or some other
possibilities.
C. The filesystem is fine but you aren't mounting it correctly. Are you
sure that you created an ext* filesystem and not some other kind? Try using
mount without -t. Are you sure that you're mounting the right device file?
The right partition?
You will treat the A and B cases differently: if it's (A), I recommend
*against* trying to recover any data in-place as has been suggested in some
other posts here. Running fsck on a dying drive can make the situation
worse (if you do it anyhow, try using the -c option as suggested elsewhere).
You should rather make an image of the drive; you need some spare space on
which to make the image. You can use something as simple as dd, but if you
encounter hardware errors while reading, try something like ddrescue. If
you still have no luck, you can move the drive to a different machine or
even replace its on-drive controller card with one from an _identical_ model
-- I have successfully done this but it is difficult and not recommended
unless you have some _very_ valuable data on that drive.
>From then on, you can treat (A) and (B) more or less the same: you might use
fsck, debugfs, etc. on the filesystem, but before modifying it, you might
want to make a copy image [in case (A) a copy of the copy] before modifying
it -- or you might just run the tools in-place. Hard to say with the
information you've provided, but from the sounds of it you may not have much
luck -- your filesystem sounds pretty sick.
If that's the case, you'll want to recover the contents rather than the
filesystem; tools like PhotoRec, foremost, scalpel [fork of foremost], etc.
will usually recover some of your files. Lots of options here:
http://www.forensicswiki.org/wiki/Tools:Data_Recovery
I should mention that in case (B) [no hardware failure], if you just want to
jump to recovering the contents rather than the filesystem, it's not
critical to make a copy image; you can just recover straight from the hard
drive.
Good luck,
-- David
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/527e4ce8.4020...@meta-dynamic.com
Re: [oclug]Re: pppoe and dsl on debian
On Thu, 9 Jan 2003, Eduard Bloch wrote: > adsl-start is Redhat-specific. No, it's not, and I think you can trust me on that. :-) -- David. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
can't yp_bind: Reason: RPC failure
When I start up NIS, 'ypwhich' gets: can't yp_bind: Reason: RPC failure and 'ypcat passwd' gets: YPBINDPROC_DOMAIN: No bound server for domain lcinc.com No such map passwd.byname. Reason: Can't bind to server which serves this domain domainname is set correctly from /etc/defaultdomain, and at one point it actually created maps in /var/yp, but n longer. What am I missing here? Thanks -- __ David Phillips Lembersky Chi Incorporated Systems Engineer651 Strander BLVD [EMAIL PROTECTED] Tukwila WA 98188 206.575.2950 (voice)206.575.2717 (fax) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
