[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 me ;-)

>> 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.

>> 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.

>> 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.
>
> Sure. I overlooked that. Thanks.

Hope this helps,

PS: I'll be travelling a bit in the next two weeks so will probably be
late again in following up.
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join