Linux question of the day

Tricky questions are actually quite hard to come up with... So thanks for the positive feedback guys

hiddenknight821 wrote: »

The more I think about it, the trickier it gets. Since I had it partially correct, I believe the `rm -rf' command didn't even execute at all, because it requires root privilege.

Not really, "rm" itself doesn't know that it requires a root privilege to finish successfully - it just tries and fails with a "permission denied" message. If I misunderstood what you meant, please tell me.

hiddenknight821 wrote: »

I might as well go ahead and **** to find out... in the VM, of course, you slick, sick, sadist.

Do go ahead and play with it, these questions are not a mental exercise as Linux is a very hands-on and practical subject. And of course you don't need to use "rm", instead substitute it with any other command. Especially useful are "debugging" commands such as "pwd", "id", "echo $VAR", "echo $?", however you must really know scope/visibility/lifetime of various elements to debug these things correctly.

hiddenknight821

ChooseLife wrote: »

Not really, "rm" itself doesn't know that it requires a root privilege to finish successfully - it just tries and fails with a "permission denied" message. If I misunderstood what you meant, please tell me.

Assuming you're talking about a typical user executing the command and the TrashCan directory has the 700 permission that belongs to root, then yes I had the right idea that root privilege was required. Otherwise, "permission denied" message is expected.

Anyway, all my guesses were wrong and I finally took your advice. After testing it, I was mind-blowned! It didn't execute at all, because 'sudo' cannot find 'cd' command. I'm glad you brought this to our attentions. Like I said, you come up with good trick questions. I'm surprised none of the books I read so far warned me about using built-in shell command with the sudo commands, especially in scripting. So next time something funny like that happen, I'd make sure to use the type/which/whereis commands before I go nuts.

hiddenknight821 wrote: »

After testing it, I was mind-blowned! It didn't execute at all, because 'sudo' cannot find 'cd' command. I'm glad you brought this to our attentions. Like I said, you come up with good trick questions. I'm surprised none of the books I read so far warned me about using built-in shell command with the sudo commands, especially in scripting. So next time something funny like that happen, I'd make sure to use the type/which/whereis commands before I go nuts.

You nailed it! Props for persistently digging to the bottom of it and finding the right answer.

So, the correct answer is:
In this example, "sudo cd TrashCan" will fail to execute because "cd" unlike many other commands is not a standalone program but rather is a shell builtin, and sudo works on standalone executable programs only. There are many ways to work around this restriction, my preference is to run it as

$ sudo bash -c "cd TrashCan && rm -rf *"

+1 excellent thread! Keep them coming

Question: I have a peculiar file named "~" in my home directory, how do I delete it?

[root@station1 ~]# ls -l
total 76
-rw-r--r-- 1 root root 0 Feb 18 12:10 ~
-rw
1 root root 1253 Oct 17 2011 anaconda-ks.cfg
drwxr-xr-x 3 root root 4096 Oct 21 2011 Desktop
-rw-r--r-- 1 root root 31401 Oct 17 2011 install.log
-rw-r--r-- 1 root root 4919 Oct 17 2011 install.log.syslog
-rw
1 root root 11727 Oct 18 2011 mbox
[root@station1 ~]#

dontstop

rm -rf -- \~

UnixGuy wrote: »

+1 excellent thread! Keep them coming

Thank you! I hope you will contribute your share of quirky questions too

dontstop wrote: »

rm -rf -- \~

agreed. for safety, i'd make couple changes to it:

a) drop "-rf" - the regular file won't need it but it can hurt if something goes sideways and the home directory will be attempted to get removed

b) throw "./" in for a good measure

so my answer is

rm -- ./\~

@dontstop & @ChooseLife

Correct answers.

This is enough though:

[root@station1 ~]# rm \~

Since we escaped the special character "~" ...RM using the full path:

[root@station1 ~]# rm ~/\~
rm: remove regular empty file `/root/~'? y
[root@station1 ~]# ls -l
total 76
-rw------- 1 root root  1253 Oct 17  2011 anaconda-ks.cfg
drwxr-xr-x 3 root root  4096 Oct 21  2011 Desktop
-rw-r--r-- 1 root root 31401 Oct 17  2011 install.log
-rw-r--r-- 1 root root  4919 Oct 17  2011 install.log.syslog
-rw------- 1 root root 11727 Oct 18  2011 mbox
[root@station1 ~]#

Question: Is KVM a Type 1 or Type 2 hypervisor? Explain your answer.

paul78

If I recall correctly - I believe that KVM is a type 1 hypervisor. It runs in the kernel directly on the hardware and exposes the hardware through a device file (can't remember which) for guest systems. It doesn't run an an app in userland which I recall is the definition of a type 2 hypervisor. Something like that

W Stewart

Okay, I've been trying to think up a question for awhile and this is something I just happened to come across a week ago.

I wrote an upstart init script and put it in the /etc/init.d/ directory. I'm using CentOS but I don't want to use chkconfig to start the service. Assuming the script has everything it needs (i.e, start on runlevel [2345]), what can I do to start the service at boot. (There's more than one way to accomplish this but the way I did it seems to be the way chkconfig does it as well.)

hiddenknight821

Well, you got a few options. The best way to be sure that you are doing them properly is to manually create the symbolic links in each desirable run-level directory under /etc/rc.d/ directory. Each symlink has to either start with 'S' or 'K' followed by a number in collating sequence with script name suffix. S is for start and K is for kill. The number is important as you may want to start up the firewall before networking. The chkconfig is doing all the dirty works for us which is implied by the `rpm -ql chkconfig' command.

The script file that each symlink is being linked to has to be placed in the /etc/init.d/ directory with all of the applicable case options such as start, stop, reload, restart, and so forth. It's probably best to use an initd script template and build the script from there.

Although, I know there is a place in /etc/rc.local where you can throw in any script that you want to run after the host's done booting up, but this wouldn't be appropriate for the iptables service. Beside, the script runs regardless of the run-level you are in.

W Stewart

hiddenknight821 wrote: »

Well, you got a few options. The best way to be sure that you are doing them properly is to manually create the symbolic links in each desirable run-level directory under /etc/rc.d/ directory. Each symlink has to either start with 'S' or 'K' followed by a number in collating sequence with script name suffix. S is for start and K is for kill. The number is important as you may want to start up the firewall before networking. The chkconfig is doing all the dirty works for us which is implied by the `rpm -ql chkconfig' command.

The script file that each symlink is being linked to has to be placed in the /etc/init.d/ directory with all of the applicable case options such as start, stop, reload, restart, and so forth. It's probably best to use an initd script template and build the script from there.

Although, I know there is a place in /etc/rc.local where you can throw in any script that you want to run after the host's done booting up, but this wouldn't be appropriate for the iptables service. Beside, the script runs regardless of the run-level you are in.

That's about how I did it. I just got a little curious about how upstart handled services after using slackware for awhile. It's very good to know.

Actually, using S and K files in /etc/rc.d/rcX.d is a fundamental way of managing daemons start/stop in System V-like Linuces (e.g. RedHat) - it is one of the differences between them and BSD-like Linuces (e.g. Slackware). Tools like chkconfig just partially automate/simplify this process.

ChooseLife wrote: »

Actually, using S and K files in /etc/rc.d/rcX.d is a fundamental way of managing daemons start/stop in System V-like Linuces (e.g. RedHat) - it is one of the differences between them and BSD-like Linuces (e.g. Slackware). Tools like chkconfig just partially automate/simplify this process.

True, that's how it's done in Solaris (up to Solaris 9). From Solaris 10 onwards, they introduced service management facility to take care of that.

paul78 wrote: »

If I recall correctly - I believe that KVM is a type 1 hypervisor. It runs in the kernel directly on the hardware and exposes the hardware through a device file (can't remember which) for guest systems. It doesn't run an an app in userland which I recall is the definition of a type 2 hypervisor. Something like that

AFAIK this is correct. The trouble is that KVM seems to have some type 2 qualities. For example, you can load/unload the kernel module for it on the fly, similar to VMware Workstation or VirtualBox. I used to think of it as a "type 1.5" hypervisor, but I attended a presentation at SCALE recently and the "chief virtualization architect" at IBM said it was definitely a type 1 hypervisor, so I'll go with that.

Okay this thread is supposed to be "question of the day", so post more questions. IMO it doesn't need to be anything tricky.

Question: It's 4:55 PM and you're about to exit your SSH sessions, power off your laptop, and go home, but your boss tells you to download a large file / compile a program / run a lengthy SQL query / etc. on a remote server before you leave so it's ready tomorrow. What should you do in your SSH session to that server to allow the task to continue when you close the session?

MentholMoose wrote: »

Okay this thread is supposed to be "question of the day", so post more questions. IMO it doesn't need to be anything tricky.

Question: It's 4:55 PM and you're about to exit your SSH sessions, power off your laptop, and go home, but your boss tells you to download a large file / compile a program / run a lengthy SQL query / etc. on a remote server before you leave so it's ready tomorrow. What should you do in your SSH session to that server to allow the task to continue when you close the session?

Put the command in a script, and run the script as a daemon. It the script name is "MentholMoose.sh":

root@server1 # nohup /MentholMoose.sh &

UnixGuy wrote: »

root@server1 # nohup /MentholMoose.sh &

+1

Somewhat related to the subject, I want to once again promote a program called "screen":

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells.
... When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the user's terminal.

(c) Screen User's Manual

It has a learning curve, but once you get the grip on it, you will be wondering how you lived without it before... I know I do...

paul78

ChooseLife wrote: »

Somewhat related to the subject, I want to once again promote a program called "screen":

Not to hijack your thread but that sounds like an opportunity to put in a plug for emacs - I prefer using the M-x shell feature.

UnixGuy wrote: »

root@server1 # nohup /MentholMoose.sh &

Followup question - how do you modify this command so that you redirect both stdout and stderr to nohup.out?

paul78 wrote: »

Followup question - how do you modify this command so that you redirect both stdout and stderr to nohup.out?

root@server1 # nohup /MentholMoose.sh 2>&1 &

bhavesh2177

"screen" is best for the situation where we want to close session, but programm should run.

Right, screen or nohup are the solutions I know of.

Question: you want to list all files in a directory that ends with *.tmp (so you can move/delete them later), and you got this error:

root@station1 # ls /var/tmp/*tmp

-/bin/bash: /bin/ls: Argument list too long

hiddenknight821

Great question! Just learned a lot from this question alone. I never had this "Argument list too long" problem before. Had to Google that one up. Apparently, I didn't get into Linux until a few years ago. So I'll not see that kind of limitation with today's hardware. I'll leave that question to someone else. Perhaps someone with 10+ year of experience.

Keep those questions coming!

paul78

UnixGuy wrote: »
Question: you want to list all files in a directory that ends with *.tmp (so you can move/delete them later), and you got this error:
root@station1 # ls /var/tmp/*tmp

-/bin/bash: /bin/ls: Argument list too long

Hmmm - my guess would be:

find . -name \*.tmp -print

hiddenknight821 wrote: »

...So I'll not see that kind of limitation with today's hardware. .

Keep those questions coming!

I got this message in new hardware, it is related to the number of files not hardware. Try to write a script that create millions or so empty files and try to list/delete them