Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Single-instance daemons

Reply
Thread Tools

Single-instance daemons

 
 
Jeffrey Barish
Guest
Posts: n/a
 
      11-12-2008
As per Stevens/Rago, "file and record locking provides a convenient
mutual-exclusion mechanism". They note the convention of putting the lock
file in /var/run in a file called <name>.pid, where <name> is the name of
the daemon and content is the pid. Seems like a good suggestion as I see
pid files from many other daemons there. However, /var/run is owned by
root, so it is not possible to write in it without root permission. I
could put the pid file in /tmp, but doing so would make it harder to find.
I could write a C program to write the lock file that takes command-line
arguments for passing the name of the daemon and the pid and give the
executable suid root, but that's a lot of bother. Has anyone else dealt
with this problem?
--
Jeffrey Barish

 
Reply With Quote
 
 
 
 
Jeff McNeil
Guest
Posts: n/a
 
      11-12-2008
On Nov 12, 4:57 pm, Jeffrey Barish <(E-Mail Removed)> wrote:
> As per Stevens/Rago, "file and record locking provides a convenient
> mutual-exclusion mechanism". They note the convention of putting the lock
> file in /var/run in a file called <name>.pid, where <name> is the name of
> the daemon and content is the pid. Seems like a good suggestion as I see
> pid files from many other daemons there. However, /var/run is owned by
> root, so it is not possible to write in it without root permission. I
> could put the pid file in /tmp, but doing so would make it harder to find.
> I could write a C program to write the lock file that takes command-line
> arguments for passing the name of the daemon and the pid and give the
> executable suid root, but that's a lot of bother. Has anyone else dealt
> with this problem?
> --
> Jeffrey Barish


Sure, start the daemon as root, write the appropriate files, and then
drop permissions using os.setegid and then os.seteuid. You can chown
the file before priv. drop to your target user so that it can be
removed when your exit handlers run. Alternatively, you can reclaim
root at cleanup as it's stored as your saved UID.

I've stopped dealing with most of the daemon specifics (session,
process group, forking & dropping TTY, PID file locations, etc...).
Each time I need to write a daemon process these days, I usually just
fall back to writing a twistd plugin. That takes care of everything
for me.

 
Reply With Quote
 
 
 
 
Jeffrey Barish
Guest
Posts: n/a
 
      11-13-2008
Jeff McNeil wrote:

> Sure, start the daemon as root, write the appropriate files, and then
> drop permissions using os.setegid and then os.seteuid. You can chown
> the file before priv. drop to your target user so that it can be
> removed when your exit handlers run. *Alternatively, you can reclaim
> root at cleanup as it's stored as your saved UID.


Nice. One thing: how do I get the uid and gid for the target user? In
general, I know the name of the target user, but the uid/gid assigned by
the OS to that user could be different on different systems.
--
Jeffrey Barish

 
Reply With Quote
 
Jeffrey Barish
Guest
Posts: n/a
 
      11-13-2008
Cameron Simpson wrote:

> Or, more simply, get root to make an empty pid file once and chown it to
> the daemon user. Then the daemon can rewrite the file as needed. You need
> to move to truncating the file instead of removing it on daemon shutdown,
> but that is trivial. And no mucking with privileges, like starting the
> daemon as root instead of directly as the daemon user, need be done.


Although the file locking that I described is happening during boot (which I
did not make clear), so I believe that the user is root already.
Accordingly, I need to drop privileges to a user anyway. Still, I like
your suggestion, so I'll remember it for another occasion.
--
Jeffrey Barish

 
Reply With Quote
 
Irmen de Jong
Guest
Posts: n/a
 
      11-13-2008

Jeffrey Barish wrote:
> Nice. One thing: how do I get the uid and gid for the target user? In
> general, I know the name of the target user, but the uid/gid assigned by
> the OS to that user could be different on different systems.


pwd.getpwnam
grp.getgrnam

--irmen
 
Reply With Quote
 
Дамјан Георгиевски
Guest
Posts: n/a
 
      11-17-2008


> As per Stevens/Rago, "file and record locking provides a convenient
> mutual-exclusion mechanism".


On linux (at least) there's one nice trick to get a single-instance
program. Create a unix domain socket, and bind it to an address that
begins with the null character '\0'. You can bind the same address a
second time, and if the process dies the socket is automatically
destroyed. It will not leave anything on the filesystem.

def single_instance(id):
import socket
s = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM)
s.bind('\0' + id)
return s


--
дамјан ( http://softver.org.mk/damjan/ )

When you do things right, people won't be sure if you did anything at all.
 
Reply With Quote
 
 
 
Reply

Thread Tools

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 On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: 2 daemons write to a single file /w python file IO Steven W. Orr Python 0 09-14-2007 08:52 PM
2 daemons write to a single file /w python file IO Andrey Python 0 09-12-2007 04:17 AM
How to write UNIX daemons in Python? gnewsg@gmail.com Python 2 09-13-2006 03:38 PM
about daemons and IPC sdistefano@gmail.com Python 4 08-29-2006 05:36 PM
Mail Daemons Mags Computer Support 4 07-01-2004 08:37 PM



Advertisments