Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

[m. allan noah]

Feel free to update the NEWS file, I'll incorporate your changes when
we ship 1.0.28

allan

On Sun, Sep 10, 2017 at 6:55 PM, Luiz Angelo Daros de Luca
 wrote:
> Hi Olaf,
>
>> Apologies for the late follow-up.  Shame on me for pinging you on the
>> bug report for no follow-up for a long time and then ignoring it when
>> you promptly send some.  :-(
>>
>
> No apologies needed. We know how it works.
>
> I was just waiting for your reply. My changes were already at github (and
> just rebased):
> https://github.com/luizluca/sane-backends/tree/reorganize-saned-args
>
>>
>> >> If there is no clear use case, perhaps saned should not provide them.
>> >> In that case, I'd remove:
>> >>  - -D and make running in the background the default because saned is
>> >>normally meant to run as a daemon
>> >
>> > I beg to disagree. It's not true for (x)inet, systemd nor procd. They do
>> > expect process in foreground. Only running saned standalone might need
>> > it
>> > to go background. Also, I think that changing the default behavior is
>> > even
>> > more traumatic than changing any behavior of options.
>>
>> Rethinking this, I guess you're right.  It's not much effort to manually
>> background a daemon, simply add an `&` at the end of the command-line.
>
>
> An `&` is not enough as there are some extra logic when going backgroud.
> `-D` do just that.
>
>> > Something for the Release Notes as Changelog is built from git log. Is
>> > there any place to save relevant changes for the next release?
>>
>> Eh, I guess the NEWS file would be as good a place as any.  Something
>> like
>>
>>   New with the development version, not yet released:
>>
>> @Allan> Does that look okay?
>>
>
> I'll just wait for the "NEWS" answered you asked @Allan in order to update
> only that and send patches to ML.
>
>>> You mention something about creating a PID file for the -u option.  That
>>
>> >> made me think a -p option to specify where you want that file might be
>> >> a
>> >> nice addition.  The current location, /var/run/saned.pid, is
>> >> hard-coded.
>> >> It's not a bad location but one may want to change it.
>> >
>> > I'll take a look. Normally PID file location is something for a
>> > configuration file.
>> > Sometimes init would like to take care of the PID file life cycle.
>> > Besides
>> > being hard-coded, if a previous PID file exists, saned should do some
>> > checks, and abort on failure. Today, if someone manage to run two
>> > instances
>> > of a stand-alone saned, the last one would simply overwrite its own PID
>> > inside the PID file. Also it should replace PID file instead of simply
>> > rewriting it. At least it would avoid different code paths (and
>> > permission
>> > requirements) whether a file at PID file exists or not.
>>
>> Looks like any user with write access to the directory holding the PID
>> file can clobber it because
>>
>>   pidfile = fopen (SANED_PID_FILE, "w");
>>
>> doesn't pass O_EXCL to the underlying open().
>>
>> On my devuan box, /var/run is a symlink to /run which has 755 perms and
>> is owned by root.  Digging further, /run is actually a mount point for a
>> tmpfs.  But anyway, not all systems are created equally.
>
>
> I'll leave PID_FILE as is for now.
>
>>
>> >> Oh, about the code changes, there are a few places in the manual page
>> >> I'd change to improve the English but I can do that for you.  There is
>> >> one mistake though, you document a -B option (as if it were -D).
>> >
>> > Yeah, english skill aren't really my "expertise". :-) I do know my
>> > limitations. Feel free to point me or correct them directly.
>>
>> I'll correct them directly (if there are any ;-).  It's less overhead
>> for both of us.
>
>
> OK for me.
>
>>
>> PS: I'll be travelling a bit in the next two weeks so will probably be
>> late again in following up.
>
>
> Nobody is at a hurry.
>
> Regards,
>
>>
>> --
>> Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
>>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>>  Support Free Softwarehttps://my.fsf.org/donate
>>  Join the Free Software Foundation  https://my.fsf.org/join
>
> --
>
> Luiz Angelo Daros de Luca
> luizl...@gmail.com



-- 
"well, I stand up next to a mountain- and I chop it down with the edge
of my hand"

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

[Luiz Angelo Daros de Luca]

Hi Olaf,

Apologies for the late follow-up.  Shame on me for pinging you on the
> bug report for no follow-up for a long time and then ignoring it when
> you promptly send some.  :-(
>
>
No apologies needed. We know how it works.

I was just waiting for your reply. My changes were already at github (and
just rebased):
https://github.com/luizluca/sane-backends/tree/reorganize-saned-args


> >> If there is no clear use case, perhaps saned should not provide them.
> >> In that case, I'd remove:
> >>  - -D and make running in the background the default because saned is
> >>normally meant to run as a daemon
> >
> > I beg to disagree. It's not true for (x)inet, systemd nor procd. They do
> > expect process in foreground. Only running saned standalone might need it
> > to go background. Also, I think that changing the default behavior is
> even
> > more traumatic than changing any behavior of options.
>
> Rethinking this, I guess you're right.  It's not much effort to manually
> background a daemon, simply add an `&` at the end of the command-line.
>

An `&` is not enough as there are some extra logic when going backgroud.
`-D` do just that.

> Something for the Release Notes as Changelog is built from git log. Is
> > there any place to save relevant changes for the next release?
>
> Eh, I guess the NEWS file would be as good a place as any.  Something
> like
>
>   New with the development version, not yet released:
>
> @Allan> Does that look okay?
>
>
I'll just wait for the "NEWS" answered you asked @Allan in order to update
only that and send patches to ML.

>> You mention something about creating a PID file for the -u option.  That

> >> made me think a -p option to specify where you want that file might be a
> >> nice addition.  The current location, /var/run/saned.pid, is hard-coded.
> >> It's not a bad location but one may want to change it.
> >
> > I'll take a look. Normally PID file location is something for a
> > configuration file.
> > Sometimes init would like to take care of the PID file life cycle.
> Besides
> > being hard-coded, if a previous PID file exists, saned should do some
> > checks, and abort on failure. Today, if someone manage to run two
> instances
> > of a stand-alone saned, the last one would simply overwrite its own PID
> > inside the PID file. Also it should replace PID file instead of simply
> > rewriting it. At least it would avoid different code paths (and
> permission
> > requirements) whether a file at PID file exists or not.
>
> Looks like any user with write access to the directory holding the PID
> file can clobber it because
>
>   pidfile = fopen (SANED_PID_FILE, "w");
>
> doesn't pass O_EXCL to the underlying open().
>
> On my devuan box, /var/run is a symlink to /run which has 755 perms and
> is owned by root.  Digging further, /run is actually a mount point for a
> tmpfs.  But anyway, not all systems are created equally.
>

I'll leave PID_FILE as is for now.


> >> Oh, about the code changes, there are a few places in the manual page
> >> I'd change to improve the English but I can do that for you.  There is
> >> one mistake though, you document a -B option (as if it were -D).
> >
> > Yeah, english skill aren't really my "expertise". :-) I do know my
> > limitations. Feel free to point me or correct them directly.
>
> I'll correct them directly (if there are any ;-).  It's less overhead
> for both of us.
>

OK for me.


> PS: I'll be travelling a bit in the next two weeks so will probably be
> late again in following up.
>

Nobody is at a hurry.

Regards,


> --
> Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
>  GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
>  Support Free Softwarehttps://my.fsf.org/donate
>  Join the Free Software Foundation  https://my.fsf.org/join
>
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

[Olaf Meeuwissen]

Hi Luiz,

Apologies for the late follow-up.  Shame on me for pinging you on the
bug report for no follow-up for a long time and then ignoring it when
you promptly send some.  :-(

Luiz Angelo Daros de Luca writes:

> Hi Olaf,
>
>> Doing the saned options the Unix way?  Great, "Do just one thing" but
>> let's also have a look at the "and do it well" part.  This is not to
>> imply that your patch is not doing things well, btw, just a little
>> reminder that that is also part of the Unix way.
>>
>> > All flags now do one thing and normally have an opposite flag that can
>> > deactivate it.
>>
>> I am not sure what you are trying to achieve with the opposite flags.
>> What use case do you have in mind for them?
>>
>> I can think of:
>>  - negating an option set in a configuration file
>>  - negating an earlier option on the command-line
>>  - signalling a running saned to toggle its behaviour
>> but none look overly compelling to me.  I even think that the first and
>> last ones are not supported by saned anyway.
>
> I cannot "negating an option set in a configuration file" as there is
> (currently) no intersection between that options and saned.conf can define.
> Also, saned reads its configuration after options were processed. Maybe it
> can change in the future.

Let's leave that for the future then.

> I was thinking "negating an earlier option on the command-line". It's
> easier when you are building the command arguments from an external
> configuration. However, I don't really have use for it yet.

If you don't have any use for it, I'd say let's not bother and focus on
getting every option to do one thing and one thing only.

>> If there is no clear use case, perhaps saned should not provide them.
>> In that case, I'd remove:
>>  - -D and make running in the background the default because saned is
>>normally meant to run as a daemon
>
> I beg to disagree. It's not true for (x)inet, systemd nor procd. They do
> expect process in foreground. Only running saned standalone might need it
> to go background. Also, I think that changing the default behavior is even
> more traumatic than changing any behavior of options.

Rethinking this, I guess you're right.  It's not much effort to manually
background a daemon, simply add an `&` at the end of the command-line.

>>  - -s and make logging to syslog the default because daemon processes
>>shouldn't scribble on anyone's terminal unless asked to
>
> Isn't it already the default? log_to_syslog is statically initialized as
> SANE_TRUE.

Correct, so you don't have to do anything to make it the default ;-)

>>  - -l and make running in stand-alone mode the default because that's
>>what daemons ought to do anyway
>
> [...]  However, I really don't like the idea of changing the default
> behavior that will surely break all current uses without a really
> strong argument. Maybe we should save it for the saned-ng, written
> from scratch. ;-)

Agreed.  Let's just get the command-line options untangled.

> I'll remove all options that replicates what is the default behavior. They
> are:
>
> -i : run inetd mode
> -D: run foreground
> -s: log to syslog
>
> # Hmm, looks like the manual page needs more changes to update the
>> # configuration sections for (x)inetd and systemd then.
>>
> Indeed. I'm not an expert on that subject.

Me neither but I think I can manage (x)inetd.

>> # BTW, the saned manual page says you cannot give options when running
>> # from (x)inetd but that is incorrect or at least outdated.
>
> Yeah, options are processed anyway. They will be accepted. I never really
> used inetd (only xinetd). Maybe when this doc was written, inetd used to
> not accept command line arguments. There is no reason for not accepting
> options and, in fact, it does accept. I would consider it just a doc
> error/outdate.

I "fixed" that in c9356cb.

>> I don't think there is any need to keep [...] options backwardly
>> compatible but it might be in order for saned to warn people that [...]
>> options have changed since 1.0.27, show the new invocation for the old
>> behaviour and a pointer to the manual page for details on the changed
>> options.
>
> Something for the Release Notes as Changelog is built from git log. Is
> there any place to save relevant changes for the next release?

Eh, I guess the NEWS file would be as good a place as any.  Something
like

  New with the development version, not yet released:

@Allan> Does that look okay?

>> Something similar could be done for -a, warning users that this option
>> is deprecated and will be removed in the future (without any explicit
>> mention of when exactly).
>
> I still think that it is not worth it. It's a problem when you does not
> have an option for changing only a specific behavior. However, a "combo
> option" that aggregates a bundle of options normally used together is good
> (just like rsync -a). My suggestion is to just keep it.

Alright.  As a fairly regular user of it, your rsync -a example
convinced 

Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

[Luiz Angelo Daros de Luca]

Hi Olaf,

>
> Doing the saned options the Unix way?  Great, "Do just one thing" but
> let's also have a look at the "and do it well" part.  This is not to
> imply that your patch is not doing things well, btw, just a little
> reminder that that is also part of the Unix way.
>
> > All flags now do one thing and normally have an opposite flag that can
> > deactivate it.
>
> I am not sure what you are trying to achieve with the opposite flags.
> What use case do you have in mind for them?
>
> I can think of:
>  - negating an option set in a configuration file
>  - negating an earlier option on the command-line
>  - signalling a running saned to toggle its behaviour
> but none look overly compelling to me.  I even think that the first and
> last ones are not supported by saned anyway.
>

I cannot "negating an option set in a configuration file" as there is
(currently) no intersection between that options and saned.conf can define.
Also, saned reads its configuration after options were processed. Maybe it
can change in the future.

I was thinking "negating an earlier option on the command-line". It's
easier when you are building the command arguments from an external
configuration. However, I don't really have use for it yet.


>
> If there is no clear use case, perhaps saned should not provide them.
> In that case, I'd remove:
>  - -D and make running in the background the default because saned is
>normally meant to run as a daemon
>

I beg to disagree. It's not true for (x)inet, systemd nor procd. They do
expect process in foreground. Only running saned standalone might need it
to go background. Also, I think that changing the default behavior is even
more traumatic than changing any behavior of options.


>  - -s and make logging to syslog the default because daemon processes
>shouldn't scribble on anyone's terminal unless asked to
>

Isn't it already the default? log_to_syslog is statically initialized as
SANE_TRUE.


>  - -l and make running in stand-alone mode the default because that's
>what daemons ought to do anyway
>

As systemd is the most used init, it is someway secure to say that
stand-alone will not be the most used "mode" of saned. (x)inetd also
requires inetd mode. procd do need stand-alone (but foreground) mode.

You may be right that a daemon (d) server should daemonize and run
background when called without options. The default behavior would only
save time when a user is calling it directly in a terminal. Extra arguments
for a init/superserver really does not make a difference. However, I really
don't like the idea of changing the default behavior that will surely break
all current uses without a really strong argument. Maybe we should save it
for the saned-ng, written from scratch. ;-)

I'll remove all options that replicates what is the default behavior. They
are:

-i : run inetd mode
-D: run foreground
-s: log to syslog

# Hmm, looks like the manual page needs more changes to update the
> # configuration sections for (x)inetd and systemd then.
>
>
Indeed. I'm not an expert on that subject.


> > The flag -a was kept compatible but, flags -d and -s now have a
> > different behavior.  -d only sets the debug level and -s only forces
> > syslog. I guess this breakage does little harm as those flags are only
> > used for dev (as they quits saned after first client).
>
> I had some doubts about -s being "only used for dev" but upon reading
> the manual page and the code, you're right.  The -s option behaves as
> the -d option.  Their only difference is in where the output goes.
>
> With that cleared up, I agree it is safe to say that no-one will be
> using these options when running their saned service as a background
> process.  If running saned on demand, e.g. via (x)inetd, you could use
> them but I would frown upon doing so for "production" use.
>
> # BTW, the saned manual page says you cannot give options when running
> # from (x)inetd but that is incorrect or at least outdated.
>

Yeah, options are processed anyway. They will be accepted. I never really
used inetd (only xinetd). Maybe when this doc was written, inetd used to
not accept command line arguments. There is no reason for not accepting
options and, in fact, it does accept. I would consider it just a doc
error/outdate.


> Systemd?  No clue how that works and very little intent to find out.
> If anyone in the know wants to chime in re running saned with these
> options they're welcome.
>

I do use systemd (it's kind of difficult to not to). I do not have a strong
option of it. I just accepted it. From what I know, it can also replace
(x)inetd calling saned whenever a client connects to a socket. The current
default behavior is enough for systemd.


>
> # FWIW, I switched to Devuan in December 2016 after using Debian for
> # about 19 years to regain init freedom ;-)  Alternative init system
> # approaches are welcome!



> Procd?  I'd think you know ;-)
>


> > If not, I can introduce new flags for those actions and 

Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

[Olaf Meeuwissen]

Hi Luiz,

Thanks for your patches.  I really appreciate that you also keep the
documentation in sync!

Luiz Angelo Daros de Luca writes:

> The two first patches are trivial bugfixes.

Indeed they are and I'll push them shortly.

> However, this one proposes a new organization on saned options, as
> shown at:
>
> https://alioth.debian.org/tracker/index.php?func=detail=315747_id=30186=410366

Doing the saned options the Unix way?  Great, "Do just one thing" but
let's also have a look at the "and do it well" part.  This is not to
imply that your patch is not doing things well, btw, just a little
reminder that that is also part of the Unix way.

> All flags now do one thing and normally have an opposite flag that can
> deactivate it.

I am not sure what you are trying to achieve with the opposite flags.
What use case do you have in mind for them?

I can think of:
 - negating an option set in a configuration file
 - negating an earlier option on the command-line
 - signalling a running saned to toggle its behaviour
but none look overly compelling to me.  I even think that the first and
last ones are not supported by saned anyway.

If there is no clear use case, perhaps saned should not provide them.
In that case, I'd remove:
 - -D and make running in the background the default because saned is
   normally meant to run as a daemon
 - -s and make logging to syslog the default because daemon processes
   shouldn't scribble on anyone's terminal unless asked to
 - -l and make running in stand-alone mode the default because that's
   what daemons ought to do anyway

# Hmm, looks like the manual page needs more changes to update the
# configuration sections for (x)inetd and systemd then.

> The flag -a was kept compatible but, flags -d and -s now have a
> different behavior.  -d only sets the debug level and -s only forces
> syslog. I guess this breakage does little harm as those flags are only
> used for dev (as they quits saned after first client).

I had some doubts about -s being "only used for dev" but upon reading
the manual page and the code, you're right.  The -s option behaves as
the -d option.  Their only difference is in where the output goes.

With that cleared up, I agree it is safe to say that no-one will be
using these options when running their saned service as a background
process.  If running saned on demand, e.g. via (x)inetd, you could use
them but I would frown upon doing so for "production" use.

# BTW, the saned manual page says you cannot give options when running
# from (x)inetd but that is incorrect or at least outdated.

Systemd?  No clue how that works and very little intent to find out.
If anyone in the know wants to chime in re running saned with these
options they're welcome.

# FWIW, I switched to Devuan in December 2016 after using Debian for
# about 19 years to regain init freedom ;-)  Alternative init system
# approaches are welcome!

Procd?  I'd think you know ;-)

> If not, I can introduce new flags for those actions and revert -d/-s
> previous behavior.

I don't think there is any need to keep these options backwardly
compatible but it might be in order for saned to warn people that these
options have changed since 1.0.27, show the new invocation for the old
behaviour and a pointer to the manual page for details on the changed
options.

Something similar could be done for -a, warning users that this option
is deprecated and will be removed in the future (without any explicit
mention of when exactly).

You mention something about creating a PID file for the -u option.  That
made me think a -p option to specify where you want that file might be a
nice addition.  The current location, /var/run/saned.pid, is hard-coded.
It's not a bad location but one may want to change it.

Oh, about the code changes, there are a few places in the manual page
I'd change to improve the English but I can do that for you.  There is
one mistake though, you document a -B option (as if it were -D).

I'd drop the SANED_EXEC_* defines you add because they're not used and
apart from a minor English nitpick in the option descriptions, the
saned.c changes look fine.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join

-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org

Re: [sane-devel] [PATCH 3/3] saned: reorganize flags, remove run_mode SANED_RUN_DEBUG

[Luiz Angelo Daros de Luca]

The two first patches are trivial bugfixes. However, this one proposes a
new organization
 on saned options, as shown at:

https://alioth.debian.org/tracker/index.php?func=detail=315747_id=30186=410366

All flags now do one thing and normally have an opposite flag that can
deactivate it.
The flag -a was kept compatible but, flags -d and -s now have a different
behavior.
-d only sets the debug level and -s only forces syslog. I guess this
breakage does little
harm as those flags are only used for dev (as they quits saned after first
client). If not,
I can introduce new flags for those actions and revert -d/-s previous
behavior.
-- 

Luiz Angelo Daros de Luca
luizl...@gmail.com
-- 
sane-devel mailing list: sane-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel
Unsubscribe: Send mail with subject "unsubscribe your_password"
 to sane-devel-requ...@lists.alioth.debian.org