Commit Graph

24 Commits

Author SHA1 Message Date
Pedro F. Giffuni
5e53a4f90f lib: further adoption of SPDX licensing ID tags.
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using mis-identified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
2017-11-26 02:00:33 +00:00
Mariusz Zaborski
1a32b20594 Limit descriptors stored in the pidfh structure.
Reviewed by:	markj, cem
Differential Revision:	https://reviews.freebsd.org/D11741
2017-08-10 16:50:13 +00:00
Mariusz Zaborski
4f9612a321 Store directory descriptor in the pidfh structure and use unlinkat(2)
function instead of unlink(2).

Now when pidfile_remove() uses unlinkat(2) to remove the pidfile
it is safe to use this function in capability mode.

Style fix: sort headers.

PR:		220524
Reviewed by:	markj
Differential Revision:	https://reviews.freebsd.org/D11692
2017-08-10 16:45:05 +00:00
Pedro F. Giffuni
872a3a62ae libutil: minor spelling fixes. 2016-05-18 15:25:45 +00:00
Jilles Tjoelker
d1d4d95209 libutil: Use O_CLOEXEC for internal file descriptors from open(). 2013-08-28 21:10:37 +00:00
Pawel Jakub Dawidek
36a00a3f38 When pidptr was passed as NULL to pidfile_open(3), we were returning
EAGAIN/EWOULDBLOCK when another daemon was running and had the pidfile open.
We should return EEXIST in that case, fix it.

Reported by:	Dirk Engling <erdgeist@erdgeist.org>
Reviewed by:	jhb, Dirk Engling <erdgeist@erdgeist.org>
MFC after:	1 week
2013-03-14 20:22:52 +00:00
Guy Helmer
fde4439701 Set the O_CLOEXEC flag when opening the pidfile to avoid leaking the
file descriptor via exec(3).

Now that daemon(8) has been fixed to resolve the issue noted by trociny,
the consensus is that this change should be OK.
2012-02-20 13:59:24 +00:00
Guy Helmer
000d6ce285 Using the O_CLOEXEC flag on open(2) caused the pidfile lock to be lost
when the child process execs daemon's target program thanks to flock(2)
semantics. So, we apparently have to leak the open pidfile's file
descriptor to keep the lock for the pidfile(3) functions to work properly.

Test case demonstrated by trociny:

ref8-amd64:/home/trociny% uname -r
8.2-STABLE
ref8-amd64:/home/trociny% daemon -p /tmp/sleep.pid sleep 10
ref8-amd64:/home/trociny% daemon -p /tmp/sleep.pid sleep 10
daemon: process already running, pid: 19799

kopusha:~% uname -r
10.0-CURRENT
kopusha:~% daemon -p /tmp/sleep.pid sleep 10
kopusha:~% daemon -p /tmp/sleep.pid sleep 10
kopusha:~%
2012-02-06 14:11:24 +00:00
Guy Helmer
47b3924be0 Move struct pidfh definition into pidfile.c, and leave a forward declaration
for pidfh in libutil.h in its place.
This allows us to hide the contents of the pidfh structure, and also
allowed removal of the "#ifdef _SYS_PARAM_H" guard from around the
pidfile_* function prototypes.

Suggested by pjd.
2012-01-12 22:49:36 +00:00
Guy Helmer
656b6da7e3 jilles pointed out that O_CLOEXEC could be used in the open(2) flags
rather than using fcntl(2) later, and in addition to saving a system
call, removes a possible race with fork/exec from threads or signal
handlers.
2012-01-11 16:35:26 +00:00
Pawel Jakub Dawidek
9de091f2ef Constify arguments. 2012-01-11 00:31:04 +00:00
Guy Helmer
4a25aa061a Style fixes courtesy of pjd. 2012-01-10 21:47:58 +00:00
Guy Helmer
f295618d06 Add pidfile_fileno() to obtain the file descriptor for an open
pidfile.
2012-01-10 19:53:25 +00:00
Guy Helmer
0dc6d4d19c Set the FD_CLOEXEC flag on the open pidfile file descriptor.
Discussed with: pjd, des
2012-01-10 18:43:27 +00:00
Pawel Jakub Dawidek
e8cc80c0a0 In pidfile_open(), if the pidfile is locked, but empty (PID is not stored yet)
and the caller requested other process' PID by passing non-NULL pidptr
argument, we will wait at most 100ms for the PID to show up in the file and if
it won't, we will store -1 in *pidptr.

From now on, pidfile_open() function never sets errno to EAGAIN on failure.

In collaboration with:	des
MFC after:		1 week
2011-10-16 21:30:15 +00:00
Dag-Erling Smørgrav
51e75198fa There is no point in releasing a lock on a file which we've unlinked and
are about to close, so don't.  As a bonus, pidfile_remove(3) will now
work with an fcntl(2)-based flopen(3).
2008-10-20 17:41:08 +00:00
Konstantin Belousov
fefc6803cf When pidfile is already locked and has zero length, do not return
success and zero pid from pidfile_read(). Return EAGAIN instead. Sleep
up to three times for 5 ms while waiting for pidfile to be written.

mount(8) does the kill(mountpid, SIGHUP). If mountd pidfile is truncated,
that would result in the SIGHUP delivered to the mount' process group
instead of the mountd.

Found and analyzed by:	Peter Holm
Tested by:	Peter Holm, kris
Reviewed by:	pjd
MFC after:	1 week
2007-10-12 10:38:05 +00:00
Dag-Erling Smørgrav
062044ebbe Back out previous commit until I figure out why my regression test fails.
Approved by:	re (kensmith)
2007-08-03 09:20:28 +00:00
Dag-Erling Smørgrav
7eb198c642 Use fcntl(2)-style locks instead of less-portable flock(2)-style locks.
Approved by:	re (kensmith)
2007-08-03 06:32:45 +00:00
Dag-Erling Smørgrav
b31d5b56ec strlcpy() may be faster than snprintf(), but it is less portable, and this
is not performance critical code anyway.  Also, avoid using strlen() to
obtain information which we already have.

MFC after:	3 weeks
2007-05-11 11:10:05 +00:00
Dag-Erling Smørgrav
3884dc6768 Use flopen(3).
MFC after:	3 weeks
2007-05-10 14:54:53 +00:00
Brian Somers
25b5a928f7 Remove some unused variables 2006-06-23 01:42:03 +00:00
John-Mark Gurney
4d5e876be3 use pwrite to always write at the begining of the file.. If multiple calls
to pidfile_write happen, the pidfile will have nul characters prepended
due to the cached file descriptor offset...

Reviewed by:	scottl
MFC after:	3 days
2006-04-11 23:10:02 +00:00
Pawel Jakub Dawidek
412fa8f114 Add a family of functions for reliable pidfiles handling.
Idea from:	jmg
Discussed on:	arch@
2005-08-24 17:21:38 +00:00