1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

built debian server to host tivo hd recordings, next steps?

Discussion in 'TiVo Home Media Features & TiVoToGo' started by markmarz, Jun 2, 2012.

  1. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL

    I was taught that a vowel is long when followed by a consonant followed by another vowel. So a short 'e' is irregular in my book. But it's actually a contraction of Debra, so Deb.
     
  2. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    It depends on the client, but yeah, mostly. The biggest time differential may be in file creation time, but with multi-Gig files, that is pretty much insignificant.

    Sending via SAMBA will certainly take less of *YOUR* time, since you don't have to have an FTP step in between. It also means a lot less time overall, since you can edit the video file directly on the server.

    What I did was create a series of directories on my Server-Main share (mapped to s: on the VideoRedo workstation) and a directory for videos (mapped to v: on the workstation). I have kmttg automatically run the videos through tivodecode to convert them .mpg and toss them to a directory on s:. Thhen kmttg automatically runs comskip on the videos to create a VRD project (.prj) file in the same directory. I edit the raw video files using the .prj files directly from the server, and then have the Batch Builder process the .prj files, implementing the cuts and recoding to h.264 in a .mp4 container, writing the temporary files to the local (to VRD) hard drive and writing the finished file to v: (or one of its directories if the program is a movie franchise installment or TV series episode). What I do then is push the processed files to one of the TiVos to check their integrity. After the files all transfer without error, I then run a routine that moves the metafiles over from the s: drive, does some extra processing on the metafiles - some interactive and some automatic, touches up the names of the video files, marks them as valid, and deletes the files on the s: drive.

    Here is the script, if you or anyone else are interested:

    Code:
    #!/bin/bash
    runDir=/usr/share/VideoScribe
    logDir=$runDir/Logs
    logFile=$logDir/verified.txt
    recDir=/RAID/Recordings
    metaDir=/RAID/Server-Main/Movies/TiVo_MPG
    tmpDir=/tmp
    monthList="Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec"
    
    filespec=$@
    
    test=1
    if [[ $1 == "--test" ]] || [[ $1 == "-t" ]]
    then
    	test=0
    	filespec=$( echo $filespec | cut -d" " -f2- )
    else
    	echo "Usage note: --test or -t => test for verification only"
    fi
    
    force=1
    if [[ $1 == "--force" ]] || [[ $1 == "-f" ]]
    then
            force=0
    	filespec=$( echo $filespec | cut -d" " -f2- )
    else
            echo "Usage note: --force or -f => force processing of files"
    fi
    
    DefaultIFS=$IFS
    abort=\<Abort\>
    [[ -z $filespec ]] && echo No Args! && exit
    #clear
    
    find "$recDir" -iname "*$filespec*.mp[4g]" > "$tmpDir"/Verify1.tmp
    
    if [[ $force == 1 ]] && [[ $test == 1 ]]
    then
    	while read fileName
    	do
    		grep -q "$fileName" "$logFile" || echo $fileName >> "$tmpDir"/Verify2.tmp
    	done < "$tmpDir"/Verify1.tmp
    	mv "$tmpDir"/Verify2.tmp "$tmpDir"/Verify1.tmp
    fi
    
    IFS=$'\n'
    fileList=$( cat "$tmpDir"/Verify1.tmp )
    
    select fileName in $fileList $abort
    do
    	IFS=$DefaultIFS
    	[[ "$fileName" == $abort ]] && exit
    	shortName=${fileName##*/}
    	echo $shortName
    	echo
    	echo -n is this correct \(Y\)?
    	tput cub 3
    	read response < /dev/tty
    	[[ -z $response || "$response" == "y" ]] && break
    done < /dev/tty
    
    if [[ $test == 0 ]]
    then
    	echo
    	grep -q "$fileName" /usr/share/VideoScribe/Logs/verified.txt
    	if [[ $? == 0 ]]
    	then
    		echo $shortName is already on the list of verified movies.
    	else
    		echo $shortName is not on the list of verified movies.
    	fi
    	echo
    	exit 0
    fi
    
    dirName=${fileName%/*}
    stubName=${shortName%.mp[4g]*}
    PrjName=$stubName.VPrj
    prjName=$stubName.Vprj
    fileType=.mpg
    echo $shortName | grep -q .mp4 && fileType=.mp4
    echo
    
    cd /usr/share/pyTivo/Unverified
    [ -a "$shortName" ] && rm "$shortName"
    [ -a "$shortName.txt" ] && rm "$shortName.txt"
    
    cd "$metaDir"
    [[ -a "$PrjName" ]] && rm "$PrjName"
    [[ -a "$prjName" ]] && rm "$prjName"
    [[ -a "$shortName" ]] && rm "$shortName"
    [[ -a "$stubName.mpg" ]] && rm "$stubName.mpg"
    [[ -a "$stubName.mpg.txt" ]] && mv "$stubName.mpg.txt" "$fileName.txt"
    [[ -a "$stubName.edl" ]] && rm "$stubName.edl"
    [[ -a "$stubName.txt" ]] && rm "$stubName.txt"
    [[ -a "$stubName.log" ]] && rm "$stubName.log"
    [[ -a "$stubName.logo.txt" ]] && rm "$stubName.logo.txt"
    
    [[ $force == 0 ]] && grep -v "$fileName" $logFile > $logFile.tmp
    [[ -a $logFile.tmp ]] && mv $logFile.tmp $logFile
    
    grep -q "$fileName" "$logFile"
    if [[ $? == 0 ]]
    then
    	echo $shortName is already on the list of verified movies.
    	echo
    	exit 0
    else
    	echo Renaming File...
    	newName=$dirName/$( "$runDir/Rename" "$fileName" )
    	echo "$newName" >> "$logFile"
    	sort $logFile > "$logFile.tmp"
    	mv "$logFile.tmp" "$logFile"
    fi
    
    cd "$dirName"
    [[ "$newName" != "$fileName" ]] && [[ -a "$fileName.txt" ]] && mv "$fileName.txt" "$newName.txt"
    [[ "$newName" != "$fileName" ]] && [[ -a "$fileName.jpg" ]] && mv "$fileName.jpg" "$newName.jpg"
    
    if [[ $fileType == ".mp4" ]] && [[ -a "$stubName.mpg" ]]
    then
    	echo
    	echo -n Remove "$stubName.mpg" \(N\)?
    	tput cub 3
    	read response < /dev/tty
    	if [[ "$response" == "Y" || "$response" == "y" ]]
    	then
    		rm "$stubName.mpg"
    		[[ -a "$stubName.mpg.txt" ]] && mv "$stubName.mpg.txt" "$stubName.mp4.txt"
    		[[ -a "$stubName.mpg.jpg" ]] && mv "$stubName.mpg.jpg" "$stubName.mp4.jpg"
    	fi
    fi
    
    touch "$newName.txt"
    touch "$newName.jpg"
    sync
    "$runDir"/NameFix "$newName.txt"
    "$runDir"/NoSpace "$newName.txt"
    
    echo
    echo Updating Links...
    
    LinkName=`echo ${newName##*/RAID/Recordings/} | sed 's/\//-/'`       # Get the root file name after the Recordings dirname for the video link
    LinkMeta="$LinkName".txt	# Set the name of the Metafile link
    LinkThumb="$LinkName".jpg	# Set the name of the Thumbnail link
    
    # Set up the Genre name array
    Genre="Action..... Adventure.. Animated... Biography.. Classic.... Comedy..... Crime...... Documentary Drama...... Family..... Fantasy.... Film_Noir.. Holiday.... Horror..... Musical.... Mystery.... Nature..... Romance.... Science.... SciFi..... Series..... Thriller... Tragedy.... War........ Western.... Done"
    
    echo
    echo ${newName##*/}
    echo
    grep vProgramGenre "$newName.txt"
    grep vSeriesGenre "$newName.txt"
    echo
    
    Gselect=""
    x=0
    select Gselect in $Genre;	# Assign Genres to the video
    do
    	if [ "$Gselect" == "Done" ]
    	then
    		break;
    	else
    		Gselect=`echo $Gselect | tr -d '.'`
    		cd /usr/share/pyTivo/pyshares/$Gselect
    		[[ -h "$LinkName" ]] || ln -s "$newName" "$LinkName"
    		[[ -h "$LinkMeta" ]] || ln -s "$newname.txt" "$LinkMeta"
    		[[ -h "$LinkThumb" ]] || ln -s "$newName.jpg" "$LinkThumb"
    		x=$(( $x + 1 ))
    		metaFields[$x]=$Gselect
    	fi
    done < /dev/tty
    grep -v vProgramGenre "$newName.txt" | grep -v vSeriesGenre > "$newName.txt.tmp"
    
    for (( y=1; y<=$x; y++ ))
    do
    	echo ${metaFields[$y]}
    	echo "vProgramGenre : ${metaFields[$y]}" >> "$newName.txt.tmp"
    done
    mv "$newName.txt.tmp" "$newName.txt"
    
    vName=${newName##*/}.txt
    datName=${newName##*Recorded }
    vName=${vName% (Recorded*}
    x=1
    for mon in $monthList
    do
    	[[ $mon == ${datName:4:3} ]] && monNum=$(( 22 - $x ))
    	x=$(( $x + 1 ))
    done
    if [[ ${datName:8:1} == "0" ]]
    then
    	dayNum=$(( 41 - ${datName:9:1} ))
    else
    	daynum=$(( 41 - ${datName:8:2} ))
    fi
    yearNum=$(( 3200 - ${datName:12:4} ))
    grep -q "$yearNum" "$newName.txt" || echo "recordDate : $yearNum$monNum$dayNum" >> "$newName.txt"
    grep -iq "isEpisodic : true" "$newName.txt" || grep -iq "firstAlpha : " "$newName.txt"
    if [[ $? != 0 ]]
    then
    	vTitle=$( grep title "$newName.txt" )
    	firstAlpha=${vTitle:8:1}
    	[[ $firstAlpha == [*\(\?] ]] && firstAlpha=${vTitle:9:1}
    	[[ ${vTitle:8:4} == "The " ]] && firstAlpha=${vTitle:12:1}
    	[[ ${vTitle:8:2} == "A " ]] && firstAlpha=${vTitle:10:1}
    	[[ $firstAlpha == [0-9] ]] && firstAlpha="0 - 9"
    	echo "firstAlpha : $firstAlpha" >> "$newName.txt"
    fi
    
    grep \| "$newName.txt" | grep -q ":"
    if [[ $? == 0 ]]
    then
    	echo -n > "$newName.txt.tmp"
    	while read metaText
    	do
    		echo $metaText | grep \| | grep -v "description" | grep -q ":"
    		if [[ $? == 0 ]]
    		then
    			colonPos=$( expr index "$metaText" ":" )
    			pipePos=$( expr index "$metaText" "\|" )
    			nameLength1=$(( ${#metaText} - $pipePos -1 ))
    			[[ $nameLength1 -lt 0 ]] && nameLength1=0
    			nameLength2=$(( $pipePos - $colonPos - 1 ))
    			[[ $nameLength2 -lt 0 ]] && nameLength2=0
    			echo -e "${metaText: 0: $colonPos} ${metaText: $pipePos: $nameLength1}${metaText: $colonPos: $nameLength2}\r" >> "$newName.txt.tmp"
    		else 
    			echo $metaText >> "$newName.txt.tmp"
    		fi
    	done < "$newName.txt"
    	mv "$newName.txt.tmp" "$newName.txt"
    fi
    
    grep -q "callsign : " "$newName.txt"
    if [[ $? != 0 ]]
    then
    	echo -n > "$newName.txt.tmp"
    	x=0
    	while read line
    	do
    		echo $line >> "$newName.txt.tmp"
    		x=$(( x + 1 ))
    		if [[ $x == 5 ]]
    		then
    			callSign=${newName##*, }
    			echo callsign : ${callSign%%)*} >> "$NewName.txt.tmp"
    		fi
    	done < "$newName.txt"
    	mv "$newName.txt.tmp" "$newName.txt"
    fi
    
    echo Done!
    
    I apologize just a bit for the lack of comments. This is pretty short and I wrote it for my own use.
     
  3. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Okay, I've got X-Ming working on my pc and have been able to login to my tivo server at a static ip with putty and then kick off a gui (Leafpad) as a test, thanks to lrhorer.:)

    But I'm still a little confused about the idea of not running X windows 'all the time' on my tivo server. I think you're saying that if I run "ssh -X" when logged in with putty that I can somehow kick off a gui on the tivo server. I tried that and got a syntax error.

    Code:
    mark@tivo-server-backup:~$ ssh -X
    usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
               [-D [bind_address:]port] [-e escape_char] [-F configfile]
               [-I pkcs11] [-i identity_file]
               [-L [bind_address:]port:host:hostport]
               [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
               [-R [bind_address:]port:host:hostport] [-S ctl_path]
               [-W host:port] [-w local_tun[:remote_tun]]
               [user@]hostname [command]
    mark@tivo-server-backup:~$
    Even so, if this did work, what would actually be happening? Would I be kicking off X on the tivo server, and if yes, how would that enable me to see the gui on my pc if I'm not running an X server there? Or maybe you're saying I do need to run X-Ming on my pc, but no X server needs to run on the tivo server all the time, instead I can kick it off adhoc using ssh -X (or whatever actually works)?

    And if I wanted to not run X all the time on the tivo server, how exactly do I disable or prevent it from running and yet be available adhoc?

    This is just for my knowledge, I haven't come down on either side of whether or not to run X all the time on a headless server because I don't know enough to form an intelligent position.
     
  4. wmcbrine

    wmcbrine Ziphead

    10,363
    22
    Aug 2, 2003
    No. You'd be using ssh to log in. Not really relevant if you want to use PuTTY. "-X" is just an ssh option that makes it easier to start X apps from the login session. I don't suppose PuTTY has an equivalent, but really, all you have to do is export the DISPLAY variable appropriately, and make sure the client isn't blocked from connecting to your X server by a firewall.

    Yes.

    No X server needs to run on the tivo server ever. You can run X apps (clients) one at a time, and all they need is an X server on any machine to connect to. The one on your PC will do fine.

    Usually it's a matter of changing the runlevel. This varies by distro. I don't know offhand for Debian.
     
  5. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    One thing that may be confusing you (it confuses a lot of people) is that the X client / server relationship is a little backwards from what most people expect. Most "servers" run on a dedicated machine, often one without a console or mouse attached. PyTivo, for example, is perfectly happy running on a headless machine. Most "clients" run on potentially multiple machines with users sitting at them. The X server (in your case Xming) is different, however. The X server runs on user machines, while the X clients run on a possibly console-less machine, but the application puts up its display on the machines running an X server.

    It doesn't particularly matter from what machine the client is spawned nor on which machine the client is displayed. One could, for example log in to machine B from machine A using telnet, set the $DISPLAY variable to point to machine C, and spawn an X app on machine B. The app would then pop up on machine C, assuming it is available and running an X server. Neither machine A nor machine B need to be running an X server in this scenario, nor do they need to be running a GUI. Either or both can be doing so, but it is not required for this example. One could also run a cron job on an X client machine to spawn a client at regular intervals. The app would then pop up on the targeted machines every time cron spawned it.
     
  6. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Right you are, of course. IOW, any means of running the X app on the client machine can be employed. It doesn't even have to be something remote to the client, but it can be. One can use rsh, ssh, telnet, PuTTY, a canned utility built in to the X server, whatever. Anything that can export the $DISPLAY variable and then run the app will work.

    He may not even have one installed. The Debian installer does not install an X server by default. As you pointed out, he also does not necessarily need to run a display manager, unless he wants to run the GUI on the TiVo server, either from the console or from XDMCP (or other remote desktop software such as VNC).

    Well, that is handled by the init scripts and the display manager. Both GDM and KDM are enabled for all runlevels other than 0, 1, and 6. I'm not certain about the display manager Mark is using, but it is likely the same. Dropping to runlevel 1 (single user) would disable the GUI, but it also disables networking. Runlevels 0 and 6 shut down the machine.

    One way to disable the GUI completely is to simply disable the display manager. This can be accomplished by putting an `exit 0` statement at the top of the init script, or by changing the runlevel parameters in the init script and updating using the update-rc.d command. I don't recommend any of these methods, however, especially if he might ever want to use the GUI.

    Now you are perfectly correct that running a GUI on a server is not considered best practice. You are also perfectly correct that having a GUI display up full time is a waste of at least some resources on the server. It is not such a terrible waste of resources, however, to leave the display manager daemon (which is tiny and uses almost no resources) running. One can also disable the GUI for the console. OTOH, even the greeter (not the full GUI) running on the console only really uses resources on the video display, and that is pretty much irrelevant to the operation of the server as a whole.

    Really, I would say as long as he does not log in on the console and does not leave an XDMCP session up all the time, he is mostly just as well not to worry about it. If he really, really wants to minimize resources, though, as I say he can disable his DM for the console but leave it active for remote logins.
     
  7. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    That is not a GUI. Leafpad is an X client displayed in an X-window on your X server. The GUI in this case is Windows, and the only GUI running on the server is (possibly) whatever is on the server's console, probably just the greeter.

    Between this and William's and my other responses, do you get the picture? This is a screenshot of KDE, the GUI I am using on my Linux systems:

    [​IMG]
     
  8. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Okay, I'll dig further and figure out what that means.

    In the meantime, thanks!

    Gotcha, thanks!
     
  9. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    I get the picture (literally);) . I was speaking loosely when I said Leafpad was a gui; of course it isn't itself a gui like windows. Then again, it's not a command line text editor; it has a graphical user interface.
     
  10. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    You hit the nail on the head, thanks! And thanks for the $DISPLAY variable explanation.
     
  11. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Yes, with the accent on the second syllable.

    Well, first of all, the accent could be on the first syllable, or even the third. Secondly, the "Deb" could be pronounced deh, duh, or dih. The ian could be pronounced eean or eyeun. Finally, the b could be part of the first or second syllable: deh-bee-un or deb-ee-un.
     
  12. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Well, to be pedantic, it requires a GUI. It's a graphical app. Windows desktop, KDE, Gnome, CDE, etc are all GUIs, sometimes called "desktop environments". (Note the "DE" in KDE, CDE, LXDE, etc.)
     
  13. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Sounds good. How do I do that? If it's somewhere in your reply, sorry I can't find it after numerous re-reads.

    KDM is my (default) display manager, though GDM is installed, and LXDE is my desktop environment.
     
  14. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    I think you're using a DM with which I am not familiar, so I'm not sure. The man pages should tell you, or the configuration file may make it readily evident. Again, look under /etc/default-display-manager. It will list something like /usr/bin/lxdm, /usr/bin/kdm, etc. Assuming it is /usr/bin/lxdm, then there is probably a directory something like /etc/lxde/lxdm. That will contain the config files. One of them should be able to specify that the console not run the GUI. Barring that, you could probably just put a trap in /etc/X11/Xsession or /etc/X11/xinit/xinitrc to check for the active display.
     
  15. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    Thanks, I'll dig around.
     
  16. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Oh, heck, how did I miss that? I'm very familiar with KDM. I don't recall at the moment off the top of my head how to disable KDM on the console, but are you really sure you want to bother? KDM just really does not eat up much in the way of resources. If you insist, I can dig into it, though.

    I don't recall if you mentioned. How much memory is on that box?
     
  17. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    4GB ram, but I could easily up that if there's a reason; I'm trying to conserve energy as much as practical and so far haven't seen a need for more ram. Right now without anything really going on the server consumes 50 watts with 3 out of 5 drives in standby. When it's humming around 80 watts tops.

    I don't insist of course! I've been digging around this whole issue and unfortunately getting more and more confused. Considering taking LXDE out of the equation, so I can more easily follow instructions for KDM/KDE. Mainly I just want to be able to turn off X unless I'm remotely logged in.
     
  18. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    No, that should be more than sufficient, with or without KDE or LXDE running on the console.

    That's not bad, at all.

    Well, that's not necessary, unless you like KDE more than LXDE. You may find yourself using neither one. As William pointed out, it is quite workable to administer the server via ssh / PuTTY and the odd X-window here and there. If you like and prefer using KDE or LXDE, then I suggest you not let performance considerations hinder you. There is a performance hit, but it is a small one, especially in a case like yours. I seriously doubt you would ever know the difference. It's also not going to impact the power consumption.

    Well, it's not a matter of "turning X off". Indeed, unless you want to exclusively administer the server using ssh or PuTTY (or telnet) directly, then you probably won't be "turning X off". OTOH, it is possible if one really wants to shut down the X listener, and this would be one option - albeit a bit of a clumsy one - for disabling KDM for the console. Note there is a significant difference between shutting down X entirely and merely not having any X sessions running. It is the individual X sessions that can potentially eat up some resources on the server, not merely having the X framework and X listener in place. It is having permanently running X sessions to which William was referring.
     
  19. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    That's all encouraging! LXDE and KDE are equally new to me; haven't used a windowing environment on the AIX or Solaris servers at work. But then I haven't administered Linux before. Thought maybe a GUI would help me ease into that, and it has been helpful at times. Other times I just get exasperated with the limitations and drop to the command line.

    I'd like to keep the GUI around as an option. From what I've read LXDE is particularly suited to low-power boxes like my own.

    I think grasping this is what's really hanging me up. Right now my server when booted brings up LXDE (and I guess KDM behind it, and X behind them both .. unless that premise is wrong, too). Anyway, isn't the GUI itself an X session on the server? Or are we only talking about X sessions in terms of remote X sessions when I'm using X-Ming on my pc?

    I think an ideal working scenario would be that Debian boots up in console mode. From there I could bring up the GUI if I wished, whether locally on the server or when remotely controlling the server. But as an option in either case. But with all the information you've given me re resources, I'm fine with having the server come up as it does now with LXDE running. If that doesn't mean I have an X session up all the time.

    Clear as mud, right?:confused:
     
  20. lrhorer

    lrhorer New Member

    6,922
    0
    Aug 31, 2003
    San...
    Well, that's good. It proves the CL is not daunting to you, so it always exists as an easy option, whether primary or secondary.

    Yours isn't all that low power, in terms of CPU and memory horsepower. For low power think: 512M of RAM and 800MHz Pentium 4. Yours is in the middle. That said, I am indeed given to understand LXDE is light on processor and memory demands, while KDE is on the heavy side. 'Still nothing like Windows, though.

    It depends on what you mean by "behind". X is the graphical system. It is the basis for all windowed operations in Linux. One cannot run any sort of graphical application, either remotely or locally, without it. The Display Manager ( XDM, KDM, GDM, LXDM, etc ) is merely a gateway to the local Desktop Environment. If a local DE (KDE, LXDE, Gnome, CDE, etc. ) is not being used, then the DM is not necessary. This is the case for text logins and for graphical apps using a remote DE. In the example of using ssh or PuTTY to log in to the workstation and bring up a window on a Windows machine, the DE is Windows, and neither a local DM nor a local DE is required for that instance. In the case of a local DE either from the console or via XDMCP, the local DM provides the login facilities and also typically allows one to select between several DEs. It's only a gateway facility, though, and essentially evaporates for the current terminal after it hands over control to the DE.

    Yes, it is.

    Not exclusively, no, but that is one example.

    In this context, Debian doesn't exactly boot up in any mode. It sounds to me like you are thinking of Linux as if it were a single user system like Windows. Each terminal has its own display attributes, and any one can be graphical or text mode. It just happens that by default Linux outputs its boot display to the console. That can be easily changed, however. Many Linux boxes output their boot display to a serial port, for example.

    It isn't running, though, unless you log in to the console (or set up an automatic, password-less console login) or through one or more XDMCP sessions. That's my point. The system you have in place right now is quite considerate of your PC's resources, and will operate swimmingly as a general purpose server, just like it sits.

    Try the following. Log out of the console, leaving the greeter (this is KDM) running. If you have any XDMCP sessions running, log out of them, as well. (You don't need to shut them down, necessarily, just log out.) Use telnet, ssh, or PuTTY to open a text terminal on the server and ps | grep for kde (or lxde, or whatever). You will see something like the following:

    Code:
    Backup:~# ps -ef | grep kde
    root     18775 18774  0 23:18 ?        00:00:01 /usr/lib/kde4/libexec/kdm_greet
    root     25883 18792  0 23:23 pts/0    00:00:00 grep kde
    
    As you can see, KDE is not running, only a single thread per active terminal for the KDM greeter. The CPU resources used by the greeter are totally trifling, and the memory eaten up by it is quite small, especially compared to 4G. Now if you log in to the GUI on one of the terminals and run the same command, you will get something like the following:

    Code:
    Backup:~# ps -ef | grep kde
    root     20883 18774  0 23:42 ?        00:00:00 /bin/sh /usr/bin/startkde
    root     21054 20883  0 23:42 ?        00:00:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
    root     21057     1  0 23:42 ?        00:00:00 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
    root     21099     1  0 23:42 ?        00:00:00 /usr/lib/kde4/libexec/start_kdeinit +kcminit_startup
    root     21100     1  0 23:42 ?        00:00:00 kdeinit4: kdeinit4 Running...                  
    root     21101 21100  0 23:42 ?        00:00:00 kdeinit4: klauncher [kdeinit] --fd=9           
    root     21103     1  0 23:42 ?        00:00:00 kdeinit4: kded4 [kdeinit]                      
    root     21109 21100  0 23:42 ?        00:00:00 kdeinit4: ksmserver [kdeinit]                  
    root     21169     1  0 23:42 ?        00:00:00 /usr/lib/kde4/libexec/polkit-kde-authentication-agent-1 -session 10b7d1636b000127518319700000031170007_1339647497_902533
    root     21171     1  0 23:42 ?        00:00:00 kdeinit4: konsole [kdeinit] -session 10b7d1636b000125714857500000109760011_1339647497_902916
    root     21231     1  0 23:42 ?        00:00:00 kdeinit Running...                      
    root     21234     1  0 23:42 ?        00:00:00 dcopserver [kdeinit] --nosid --suicide  
    root     21236 21231  0 23:42 ?        00:00:00 klauncher [kdeinit] --new-startup       
    root     21240     1  0 23:42 ?        00:00:00 kded [kdeinit] --new-startup            
    root     22674 21100  0 23:43 ?        00:00:00 kdeinit4: kio_trash [kdeinit] trash local:/tmp/ksocket-root/klauncherT21101.slave-socket local:/tmp/ksocket-root/krunners21132.slave-socket
    root     24090 18792  0 23:44 pts/0    00:00:00 grep kde
    
    Those are some of the resources of which William was speaking, and although they are not massive, they do represent a little something in the way of a drain on the server. This can be completely avoided, however, by simply not logging in.
     

Share This Page