Hi,
I've tested you implementation. owserver is started by systemd when
for example owget tries to connect - great! I'm sending three patches,
first updates autotools machinery to use proper --prefix in units and
copy the units during "make install".
second adds unit for socket activation and
Tomasz,
The systemd branch in owfs-code git is making progress.
I've added the socket initiation, and the sd-notify.
We stay in foreground more if systemd is the starting method, and ignore
port assignments from the configuration file and command line.
I do need to test and add more informative m
On Wed, Jun 11, 2014 at 07:04:28AM -0400, Paul Alfille wrote:
> Ok, I started a branch called systemd with the two files sd-daemon.c and
> sd-daemon.h included.
>
> A few things look a little strange -- systemd listen sockets are
> automatically assigned as file descriptors number 3, 4, 5. I guess
You mention a couple of concepts: "persistence" and "caching" that I think
are orthogonal to the systemd -- at least in owfs's view of them.
1. Caching is the storing of 1-wire slave readings (in owserver) for a
short while to work around the relatively slow 1-wire bus speeds. It should
always be
Hi,
How will this handle the persistent features? As I understand ownet does
cache values for example. If the listener is handled externally and ownet
is not running generally, would it have to use disk as persistence?
Vajk
On Thu, Jun 12, 2014 at 1:50 PM, Jan Kandziora wrote:
> Am 12.06.2014
Am 12.06.2014 12:38, schrieb Paul Alfille:
> So can we have the situation where owserver waits for both
>
> 1. the USB device (say) to be available
> 2. a request to come in
>
> and appear always available to the clients?
>
As systemd handles the socket connection (and process start) alone, I
th
So can we have the situation where owserver waits for both
1. the USB device (say) to be available
2. a request to come in
and appear always available to the clients?
On Wed, Jun 11, 2014 at 7:59 AM, Jan Kandziora wrote:
> Am 11.06.2014 13:04, schrieb Paul Alfille:
> >
> > Also, in the docume
Am 11.06.2014 13:04, schrieb Paul Alfille:
>
> Also, in the documentation about systemd, there was a long passage about
> how the daemonizing should be done external to the program -- is that still
> the recommended policy? I guess the early testing could help there.
>
Yeah, that's one of the key
Ok, I started a branch called systemd with the two files sd-daemon.c and
sd-daemon.h included.
A few things look a little strange -- systemd listen sockets are
automatically assigned as file descriptors number 3, 4, 5. I guess we'll
have to test systemd very early to make sure no other file descri
On Thu, Jun 05, 2014 at 05:34:01PM -0400, Paul Alfille wrote:
> Tomasz,
>
> I'm having trouble visualizing how the systemd triggering works. When a
> program like owread tries to contact owserver, is owserver started? Is this
> done by monitoring the typical owserver port (4304)? How about other
>
Tomasz,
I'm having trouble visualizing how the systemd triggering works. When a
program like owread tries to contact owserver, is owserver started? Is this
done by monitoring the typical owserver port (4304)? How about other
owserver friends?
If you don't mind describing the process more, or givi
On Thu, Jun 05, 2014 at 11:24:47AM -0700, Jerry Scharf wrote:
> Tomasz,
>
> This would need to be an option rather than the default operation mode.
> Not everyone can/will run owserver and friends from systemd.
Systemd's socket activation design makes it very easy to gratefuly
fallback into st
Tomasz,
This would need to be an option rather than the default operation mode.
Not everyone can/will run owserver and friends from systemd.
jerry
On 06/05/2014 07:26 AM, Tomasz Torcz wrote:
> On Tue, Jun 03, 2014 at 10:17:14PM -0400, Paul Alfille wrote:
>> Tomasz, would you use dbus for system
On Tue, Jun 03, 2014 at 10:17:14PM -0400, Paul Alfille wrote:
> Tomasz, would you use dbus for systemd? And would you send 1-wire data that
> way or just program control.
>
> Looking at dbus, it certainly looks like 1-wire data could map to it
> easily. I'm just not sure if it would be useful.
My intention is to use owserver only for debugging purposes (with fake or
simulated devices). I have access only to a macbook and it makes not much sense
to use it as a "real" server. My point is simply that owfs used to compile on
Darwin, while now it is dead... so no intention to port it under
Am 04.06.2014 04:17, schrieb Paul Alfille:
> Tomasz, would you use dbus for systemd? And would you send 1-wire data that
> way or just program control.
>
> Looking at dbus, it certainly looks like 1-wire data could map to it
> easily. I'm just not sure if it would be useful.
>
IIRC, dbus is
* fa
Tomasz, would you use dbus for systemd? And would you send 1-wire data that
way or just program control.
Looking at dbus, it certainly looks like 1-wire data could map to it
easily. I'm just not sure if it would be useful.
Paul
On Tue, Jun 3, 2014 at 4:57 PM, Tomasz Torcz wrote:
> On Mon, Jun
On Mon, Jun 02, 2014 at 09:27:05PM +0200, Stefano Miccoli wrote:
> Dear all:
>
> I tried to compile owfs on recent Darwin (OS X Mavericks), hitting against a
> number of problems, the biggest being how semaphores are implemented.
>
> I decided to tackle the problem starting from the simplest (tr
Your changes were applied, Stefano.
Jan, I'd be happy to make any changes that ease package maintainer's work.
On Tue, Jun 3, 2014 at 9:08 AM, Stefano Miccoli wrote:
> No, I do not think: I addressed only problems on Darwin.
>
> BTW I tested my patch under the assumption that manpages are inst
No, I do not think: I addressed only problems on Darwin.
BTW I tested my patch under the assumption that manpages are installed in a
tree which is distinct from the system one: I do not know how package
maintainers will address this layout. The idea is to keep upstream as simple as
possible and
Am 03.06.2014 09:02, schrieb Stefano Miccoli:
> Do you mean installcheck?
>
> I was unaware of such a problem: both 'make check' and 'make
> installcheck' do nothing in src/man, since no test suite is defined.
>
No, the "checkinstall" program which creates RPM and DEB packages just
from a Makefil
Do you mean installcheck?
I was unaware of such a problem: both 'make check' and 'make installcheck' do
nothing in src/man, since no test suite is defined.
S.
On 02 Jun 2014, at 23:32, Jan Kandziora wrote:
> Am 02.06.2014 21:27, schrieb Stefano Miccoli:
>>
>> This target (which I would call
Am 02.06.2014 21:27, schrieb Stefano Miccoli:
>
> This target (which I would call rather call a "sed hell") tries to
> cope with a simple problem: the manpages contain '.so file' requests
> which cannot be resolved properly by the man system.
>
Thank you for addressing this. Does it also fixes th
23 matches
Mail list logo
