Jonas Smedegaard <dr@jones.dk> writes in Bug#590544: Regarding errors in log messages.... If there is an error in /etc/kannel/kannel.conf (e.g. if it tries to set a configuration variable that Kannel does not support), then bearerbox fails not start, but the error message is not logged anywhere in /var/log. This makes the configuration error difficult to find and fix. strace shows that bearerbox tries to write error messages to stderr but gets ENOSPC because run_kannel_box has redirected fd 2 to /dev/full. As a workaround, one can run bearerbox in a tty and see the error messages that way. However, that requires a cumbersome invocation of sudo or su if one wants the bearerbox process to get the same uid and gid as when started from the init script. If you're going to revise the init scripts, then perhaps you can get rid of run_kannel_box altogether and instead have the init system (systemd or whatever) restart the boxes if they die for any reason. That way, the init system would also be in a position to log the signal that killed the process. There Kannel boxes can be configured to write their messages to syslog, but AFAIK that requires setting the syslog-level variable in kannel.conf, so it won't help if the problem is with kannel.conf itself. Also, the messages written to /var/log/kannel/ often appear to include passwords, so I'm wary of writing them to syslog.
Quoting Kalle Niemitalo (2015-07-30 11:09:44) Oh my... Do you know if upstream is already aware of that issue? Seems better if we could hack (or have upstream fix) run_kannel_box to behave more sensibly - or if there are sane use cases for it then fork and adapt for what is sensible as _init_ script. 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? 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. 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. How does that all sound? An, would you like to join the Debian Kannel team and collaborate directly on maintaining this package? You need not formally be a Debian Developer to join our team. - Jonas
Jonas Smedegaard <dr@jones.dk> writes: 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" Because run_kannel_box is apparently deprecated, I don't think I should spend my employer's time on improving it. 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. OK. Currently though, the files in /var/log/kannel are not world-readable, so writing passwords there is not too bad. I'd rather not. I intend to stop fixing Kannel bugs when I get it working sufficiently well in my employer's environment.
Quoting Kalle Niemitalo (2015-07-31 20:15:19) Makes sense. Thanks for digging up those details. 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. /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). Fair enough. I appreciate all your bugreports and input here! I owe you a beer - and your emplyer as well :-) - Jonas
Jonas Smedegaard <dr@jones.dk> writes: I would think run_kannel_box and --parachute are themselves emergency features. Although I build Kannel from a source tree based on your Debian sources, we actually run it on Ubuntu 14.04 LTS with Upstart. Job configuration files for that would therefore be more useful to us. I guess you won't want to spend time on them though, now that Ubuntu too has switched to systemd.