LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 01-06-2013, 07:19 PM   #1
fantasy1215
Member
 
Registered: Oct 2011
Posts: 70

Rep: Reputation: Disabled
What happens to a ln soft link program?


My system information is as below:
Code:
#uname -a
Linux myserver 2.6.18-128.el5PAE #1 SMP Wed Dec 17 12:02:33 EST 2008 i686 i686 i386 GNU/Linux
I create a socket server program never exit, then I create a soft link to link it.
Code:
ln -sf realprogram linkname1
and then start linkname1 at background.
Code:
linkname1 &
Now I modify the code of realprogram and recompile and overwrite realprogram(which succeeded), at the same time I never exit or restart "linkname1".
And I found linkname1 not update to the modified code.
Can someone tell me the detail internal mechanism of it? Thanks in advance.
 
Old 01-06-2013, 08:38 PM   #2
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,343

Rep: Reputation: 575Reputation: 575Reputation: 575Reputation: 575Reputation: 575Reputation: 575
The linker does not write directly to the existing realprogram file but writes to a temporary file name and then renames the temp file to "realprogram", leaving the running process executing a now unnamed file. If you were to run
Code:
ls -l /proc/$(pidof linkname1)/exe
you would see the link marked as "(deleted)".

linkname1 will still point to the same name as before (realprogram), but following that link should get the new content. Are you doing this on a locally mounted filesystem, or is it remote via NFS? There might be some NFS caching weirdness going on. I'm by no means an expert on that.
 
Old 01-06-2013, 08:46 PM   #3
fantasy1215
Member
 
Registered: Oct 2011
Posts: 70

Original Poster
Rep: Reputation: Disabled
Quote:
The linker does not write directly to the existing realprogram file but writes to a temporary file name and then renames the temp file to "realprogram", leaving the running process executing a now unnamed file.
Thanks for your reply. But Sorry I don't understand what this mean.
 
Old 01-07-2013, 02:52 AM   #4
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,571

Rep: Reputation: 471Reputation: 471Reputation: 471Reputation: 471Reputation: 471
In small words: you cannot change the program under a running process, even if you delete and recreate the binary executable (that's what linker does).
On the other hand, overwriting the executable (or a shared lib it uses) will lead to unpredictable errors, most likely abnormal termination. Symbolic (or other) links don't matter. So you have to restart your server-program, whenever you recreate it.
 
Old 01-07-2013, 03:20 AM   #5
pan64
Senior Member
 
Registered: Mar 2012
Location: Hungary
Distribution: debian i686 (solaris)
Posts: 4,466

Rep: Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213
you can imagine the following: when you start a program it will be copied into the memory (from the filesystem) and will be executed from memory. Modifying the file afterward will not affect that copy and the execution.
 
Old 01-07-2013, 05:05 AM   #6
melinda_sayang
Member
 
Registered: Dec 2003
Location: Petaling Jaya
Distribution: Ubuntu
Posts: 475

Rep: Reputation: 31
Quote:
Originally Posted by pan64 View Post
you can imagine the following: when you start a program it will be copied into the memory (from the filesystem) and will be executed from memory. Modifying the file afterward will not affect that copy and the execution.
I am just wondering. How hard in OP's case to change the memory so the execution of the program will be updated accordingly?
 
Old 01-07-2013, 05:37 AM   #7
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,571

Rep: Reputation: 471Reputation: 471Reputation: 471Reputation: 471Reputation: 471
Overwriting the program's memory will cause unpredictable errors and abnormal termination (overwriting the binary file may cause this, as it is still used when pages of the code are swapped out and needed to be reloaded).
If you want something like that, periodically check from the program the date of the executable (with stat(2)), and use exec* to replace the current process when necessary. (A more sophisticated approach is using a minimal core and a shared lib which can be replaced with dlcose+dlopen)
 
Old 01-07-2013, 06:34 AM   #8
pan64
Senior Member
 
Registered: Mar 2012
Location: Hungary
Distribution: debian i686 (solaris)
Posts: 4,466

Rep: Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213Reputation: 1213
Quote:
Originally Posted by NevemTeve View Post
Overwriting the program's memory may cause unpredictable errors and abnormal termination
30 years ago (C64, ZX Spectrum) it was a common practice: "usually" those programs modified themselves. But it is history now.
 
Old 01-07-2013, 06:45 AM   #9
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,571

Rep: Reputation: 471Reputation: 471Reputation: 471Reputation: 471Reputation: 471
Yeah, but then program modified itself; but now it is about replacing the code of a running process "from outside".
 
Old 01-08-2013, 08:48 AM   #10
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,395
Blog Entries: 2

Rep: Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903Reputation: 903
I think the key concept is that there are two distinct things involved. One is a file, and I don't think it matters that the file is open or has any kind of links to it. The other is a process. Nothing can modify the properties of a process (except killing the process by sending an uncatchable signal), except the process itself. Modifying the file does not affect the process, even though the process was started by loading object code that came from the file.

--- rod.

Last edited by theNbomr; 01-08-2013 at 08:50 AM.
 
Old 01-08-2013, 08:59 AM   #11
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,571

Rep: Reputation: 471Reputation: 471Reputation: 471Reputation: 471Reputation: 471
What happens, when a memory-page of the code gets swapped out? Well, as it is read-only, it won't be actually written to the swap-file, instead when it is needed again it will be reloaded from the binary executable file. If the file has been changed that will lead to random errors.
 
1 members found this post helpful.
Old 01-08-2013, 10:44 AM   #12
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 1,343

Rep: Reputation: 575Reputation: 575Reputation: 575Reputation: 575Reputation: 575Reputation: 575
Quote:
Originally Posted by NevemTeve View Post
What happens, when a memory-page of the code gets swapped out? Well, as it is read-only, it won't be actually written to the swap-file, instead when it is needed again it will be reloaded from the binary executable file. If the file has been changed that will lead to random errors.
And that is why the kernel will not allow you to write to the file of an executable or library that is in use by a running process. If you try, you get an ETXTBSY (Text busy) error.
 
1 members found this post helpful.
Old 01-08-2013, 11:03 AM   #13
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 1,571

Rep: Reputation: 471Reputation: 471Reputation: 471Reputation: 471Reputation: 471
Yes, that's true. On the other hand, once I could somehow overwrite a shared library while it was used by a running program, which then crashed because of that.
 
Old 01-08-2013, 11:07 AM   #14
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,046

Rep: Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100
Quote:
Originally Posted by theNbomr View Post
Modifying the file does not affect the process, even though the process was started by loading object code that came from the file.
I think NevemTeve has already explained why your statement would be incorrect if you actually do modify that file (not a new file of the same name).

The process remains tied to the file. Pages can be read from that file long after the process is "started".

In the common situation, one can delete and recreate the file with different contents, so the filename in the directory is now associated with a different file. But the original file is not actually deleted as long as it is held open by that process.

The OP seems to be asking about a more complicated case in which there is also a soft link to the file. The OP seems to be saying the soft link remains connected to the old file (that only still exists because the process has it open) and does not connect to the new file.

I find that surprising, but I don't recall enough about soft links to be sure, nor do I have time now to test this behavior myself.

Quote:
Originally Posted by fantasy1215 View Post
Thanks for your reply. But Sorry I don't understand what this mean.
It is rare for programs to open existing files and incrementally overwrite their entire content. Writing part of an existing file is usually done only in cases where you really need to write part of an existing file.

When a program wants to replace all of an existing file, it typically deletes the existing file and creates a new file of the same name as the previous file.

That approach enables the Linux feature of not really deleting a file if some other process has that file open during the delete request. The file only loses its name when you try to delete it. Once no process has the file open, it actually gets deleted.

rknichols described the concept of delete and replace plus the common extra safety feature of starting with a temporary file. That allows the program to delay deleting the original until it is done writing the new one, so in case of error during the write, the old version is safe. That extra level of safety was not really relevant to the basic topic of your question: At whatever moment a file is deleted, if that file is still open by some process it isn't really deleted; It just loses its connection from its name in the directory. The true delete is delayed until the file is no longer open.

Quote:
Originally Posted by pan64 View Post
you can imagine the following: when you start a program it will be copied into the memory (from the filesystem) and will be executed from memory. Modifying the file afterward will not affect that copy and the execution.
But imagining it that way leads to misunderstanding. When you start a program, it will map (not copy) parts of that file onto parts of your virtual address space. Whenever the process happens to use mapped pages, the kernel may read or reread those pages from the mapped file.

Last edited by johnsfine; 01-08-2013 at 11:27 AM.
 
Old 01-09-2013, 06:14 PM   #15
Peverel
Member
 
Registered: May 2009
Location: Chelmsford, England
Distribution: OpenSuse 11.3, 11.4 and 12.2
Posts: 97

Rep: Reputation: 21
Perhaps it might help to describe briefly how files and links are implemented.

A physical file is in three parts:
a directory entry (aka hard link) consisting of the file name and a pointer to:
an i-node (file descriptor) which contains a description of the file (type, dates, permissions, etc) and
if a directory, directory entries,
if a soft link, the complete path to the directory entry of the linked file,
otherwise, pointers to blocks containing the data of the file (such as text or code).

Normally, if a file is edited, the last two are replaced by new ones to which the old directory entry is redirected: a new directory entry is created to point to the old file descriptor as a back-up file. consequently, any soft link to this file is still valid, i.e. points to the original directory entry. However, when compiling and loading a file, the old directory entry cannot be used, since as rknichols points out, the new executable file has originally a different temporary name, and so different directory entry, whose name is subsequently replaced. However, the soft link points to an absolute address, which is the old, superseded, directory entry.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference Between Soft Link & Hard Link rajaniyer123 Solaris / OpenSolaris 16 09-30-2012 03:42 AM
soft link puntino Linux - Newbie 9 03-30-2012 03:31 AM
create soft link and hard link in RHEL5 ramadas88 Linux - Server 6 09-15-2010 04:32 AM
hard link and soft link varunrapelly Linux - Newbie 9 10-02-2008 07:05 AM
Soft Link and Hard Link Moataz Red Hat 1 04-25-2005 06:30 AM


All times are GMT -5. The time now is 10:23 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration