[Pkg-kannel-devel] Bug#794065: Bug#794065: kannel: run_kannel_box prevents logging of kannel.conf errors

[Jonas Smedegaard]

Quoting Kalle Niemitalo (2015-07-31 20:15:19)
> Jonas Smedegaard <dr at jones.dk> writes:
>> Oh my... Do you know if upstream is already aware of that issue?
> 
> I found these in redmine:
> 
>   https://redmine.kannel.org/issues/116
>   "run_kannel_box should be deprecated in favor of --parachute"
> 
>   https://redmine.kannel.org/issues/69
>   "Patch to provide syslog support to run_kannel_box"
> 
> and from mailing lists:
> 
>   http://article.gmane.org/gmane.comp.mobile.kannel.user/10727
>   Subject: RE: disable output to stdout
> 
>   http://article.gmane.org/gmane.comp.mobile.kannel.devel/24815
>   Subject: Re: run_kannel_box - forcing umask to be 077
>   "please stop using run_kannel_box because it's deprecated"
>
>> It might be as simple as commenting out line run_kannel_box.c line 
>> 393 (calling rebind_standard_streams() ), but I would love someone 
>> else than me to hack it - someone more fluent in C and knows the 
>> details of what exactly is needed to spawn a background process 
>> reliably.  You, perhaps?
>
> Because run_kannel_box is apparently deprecated, I don't think
> I should spend my employer's time on improving it.

Makes sense.  Thanks for digging up those details.


>> I don't like the "for any reason" - I can imagine sane reasons for 
>> dying that shouldn't be turned into init system looping like crazy.
>
> sysvinit is able to respawn processes listed in /etc/inittab if they 
> die, and there is a "respawning too fast: disabled for %d minutes" 
> limit.  This "respawn" feature of sysvinit is normally used only for 
> getty and sulogin, but the equivalent feature of Upstart seems to be 
> used for pretty much any service one wants to keep running.  I'm not 
> familiar with systemd but I imagine it too has something similar.

Right.  I am aware but consider that an emergency feature.  But you've 
convinced me that even though ugly it is arguably the better to rely on 
init system capturing loops than using run_kannel_box - until Kannel 
maybe comes up with better handling in some future release.

As mentioned earlier (or in another bugreport? - you've filed so many 
lately :-) ) I want to split into a single init script for each daemon.

If you wanna help speed up fixing this bug, one way you can help is to 
make draft init scripts based on /lib/init/init-d-script - i.e. in the 
style of recent /etc/init.d/skeleton - and test that the respawning 
works for both sysvinit and systemd-init.

I am not yet comfortable writing systemd init scripts, so would myself 
just rely on its ability to use legacy sysvinit scripts.  If you wanna 
also make draft systemd scripts then that's certainly appreciated but 
not really needed IMO.


>> Makes sense to leak passwords at debug-grade verbosity levels.
>>
>> If code leaks passwords at less verbose levels, we should patch that 
>> (and make upstream aware).
>>
>> If default config/init sets debug-grade verbosity we should fix that.
>>
>> Other than that we can perhaps add comment in config file to warn 
>> about such leakage when raising verbosity.
>
> OK.  Currently though, the files in /var/log/kannel are not 
> world-readable, so writing passwords there is not too bad.

/var/log/syslog is also not world readable.

Anyway, this is probably better suited to discuss at bug#788816 (now 
that I am convinced to avoid run_kannel_box so it is not needed as 
argument for that).


>> An, would you like to join the Debian Kannel team and collaborate 
>> directly on maintaining this package?
>
> I'd rather not.  I intend to stop fixing Kannel bugs when I get it 
> working sufficiently well in my employer's environment.

Fair enough.

I appreciate all your bugreports and input here!  I owe you a beer - and 
your emplyer as well :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-kannel-devel/attachments/20150731/4221ad99/attachment.sig>