*nix

unless i'm mixing things up myself now, forking and detaching are different things - but i guess that has been handled in other packages many times before

You're correct. Detaching is forking and exiting as opposed to forking children.

Just curious: I notice that this is assigned to be fixed in versions that are already out. Does anyone have an estimate for which version this feature may be included with? I know this is one among many other requests; I really appreciate the consideration.

If I'm just JIRA-ignorant and unable to see where this data is, I apologize.

"Fix Version/s:" seems to be "None". you probably mixed it up with "Affects Version/s:"

Is there any workaround to run the zabbix_server under supervision while Zabbix developer consider to implement this feature?

I'd like to point out that such supervisors are currently replacing the old SysVInit on most major linux distributions (Upstart on Ubuntu/RHEL/CentOS/Oracle Linux, Systemd on Fedora,(Open-)SuSE, RHEL7,Debian testing). The missing ability to not fork the Zabbix processes makes it increasingly difficult to properly package Zabbix for those distributions. I know that Zabbix SIA has never had much interest in proper downstream deployment, but at this rate I doubt my major distributions will ship Zabbix packages in the future.

I'd love to have it implemented in 2.2. It doesn't look like a huge development.

According to our AIX administrators this feature is necessary for managing Zabbix in a native way via the AIX subsystem.
See mkssys and related commands.

This is a patch that provides the foreground option for the proxy, agent and server.

I tried to make it as clean as possible, by adhering to coding standards and the general framework thats already in place.

Edwin

edwin-

this looks great! just applied and testing... thank you!

as I did not know about this patch I have created new from scratch...
For more info on them (and they are almost same as this just coding a bit different)
ZBXNEXT-2293

latest patch doesnt work with at least the zabbix_proxy - even though it lists -f as a flag it is rejected – reverted back to 2.2.1

Missing part of code while backporting from trunk
Fixed proxy startup missing -f handling

any chance to get this into zabbix soon? atm we build a zabbix Infrastructure with linux container technology (docker), so this option would be really nice!

hmm.. trying the new patch and getting and error in daemon.c?

Making all in zbxnix
depbase=`echo daemon.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
	gcc -DHAVE_CONFIG_H -I. -I../../../include     -g -O2    -MT daemon.o -MD -MP -MF $depbase.Tpo -c -o daemon.o daemon.c &&\
	mv -f $depbase.Tpo $depbase.Po
In file included from daemon.c:21:
../../../include/daemon.h:34:8: error: conflicting types for 'daemon_start'
int    daemon_start(int allow_root, int run_foreground);
       ^
../../../include/daemon.h:33:5: note: previous declaration is here
int     daemon_start(int allow_root);
        ^
daemon.c:144:5: error: conflicting types for 'daemon_start'
int     daemon_start(int allow_root, int run_foreground)
        ^
../../../include/daemon.h:33:5: note: previous declaration is here
int     daemon_start(int allow_root);
        ^
2 errors generated.
make[3]: *** [daemon.o] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I apologize again ...
please remove line 33 in daemon.h or apply v3 patch...
and manually tested this time:

steki@pc:~/projects/zabbix-2.2.3> ./src/zabbix_proxy/zabbix_proxy -f -c /home/steki/projects/zabbix-2.2.3/conf/zabbix_proxy.conf 
zabbix_proxy [22564]: Running in foreground...
^Csteki@pc:~/projects/zabbix-2.2.3>
steki@pc:~/projects/zabbix-2.2.3> ./src/zabbix_server/zabbix_server -f -c /home/steki/projects/zabbix-2.2.3/conf/zabbix_server.conf 
zabbix_server [22456]: Running in foreground...
^Csteki@pc:~/projects/zabbix-2.2.3>
steki@pc:~/projects/zabbix-2.2.3> ./src/zabbix_agent/zabbix_agentd -f -c /home/steki/projects/zabbix-2.2.3/conf/zabbix_agentd.conf 
zabbix_agentd [22601]: Running in foreground...
^Csteki@pc:~/projects/zabbix-2.2.3>

looks like it works! thanks!

Updated patch to released version 2.4.0

Thank you, very useful for Docker integration.

hi all
Boris, can you state explicitly the license of your patch
(see also http://elinux.org/Developer_Certificate_Of_Origin)

This confirms that patches that i post here on zabbix support, zabbix wiki or zabbix mail lists are under same license as zabbix itself (GPL-2.0+ )

Need this to run with runit process supervisor.

And to run it properly on a Docker container, it should have an option to log everything to STDOUT, so that logs can be managed by the Docker engine.

If the process is running in foreground, is that enough to get logs to STDOUT, or this should need another patch ?

Hi,

Looking at the comments i see foreground patch is added to version 2.4.0. I'm currently using version 2.4.5. but unable to start the zabbix-agentd in foreground.I'm getting following error . Can anyone please help ?

zabbix-agentd/sbin/zabbix_agentd -f -c zabbix-agentd/etc/zabbix_agentd.conf
zabbix_agentd [31087]: illegal zbx_option – f
usage: zabbix_agentd [-Vhp] [-R <runtime option>] [-c <config-file>] [-t <item key>]

sorry for confusion, but this patch is still NOT accepted into mainline zabbix, in current incarnation it is half functional regarding systemd (or what ever you prefer as init/startup system)
in current state it does not take care of logging as commented by endersonmaia in comment above, for me patch work "just fine" but from QA perspective it is still not finished. Maybe i will find time to fix this - or maybe just setting up logfile to be /dev/fd/1 is sufficient. Last part of logging i would give you as an exercise

Thank you for your reply Boris.I was unable to find clear steps to apply this patch. How can I build zabbix 2.4.5 with this patch?

If you do not know how to patch it itself i highly suggest to use official zabbix appliance or use openSUSE packaged version which include this patch in source rpm
https://build.opensuse.org/package/show/server:monitoring/zabbix and 2.4.x version at https://build.opensuse.org/package/show/server:monitoring:zabbix/zabbix24

same problem with OS X service-management framework - launchd

You must not daemonize your process. This includes calling the daemon function, calling fork followed by exec, or calling fork followed by exit. If you do, launchd thinks your process has died. Depending on your property list key settings, launchd will either keep trying to relaunch your process until it gives up (with a “respawning too fast” error message) or will be unable to restart it if it really does die.

Updated patch to work with zabbix 3.0.0 alpha 3 release

I think that we'll manage to include it into 3.0. First version of the specification is ready and available at https://zabbix.org/wiki/Docs/specs/ZBXNEXT-611.

In (4) of ZBX-9824 will be done changes for zabbix java gateway, to use as similar approach as possible to run the gateway in foreground.

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBXNEXT-611

(1) Only the long "--foreground" option has been added. It is suggested to add "-f", too.

wiper RESOLVED in r57492

asaveljevs CLOSED

(2) Unix "man" pages should be updated.

wiper RESOLVED in r57538

asaveljevs CLOSED

(3) If the agent is started with "-h" option and "--foreground", it is designed to complain:

zbx_error("foreground option can be used only when running Zabbix agent");

It is however unclear what the problem is from this message alone - if we are starting the agent with "-h" option, we are technically running it, too.

wiper Actually it would work wiith -h and -V options, but would complain about -p and -t options, which is even worse. We decided to allow -f option to work with all other options except windows service management options.
RESOLVED in r57496

asaveljevs CLOSED

(4) Is it OK that in zabbix_agentd.c t->flags = ZBX_TASK_FLAG_FOREGROUND unconditionally overrides the earlier t->flags = ZBX_TASK_FLAG_MULTIPLE_AGENTS?

wiper Agent will complain if -m option is used wihtout -idsx options, or if -f option is used with -idsx options.
RESOLVED in r57496

asaveljevs It seems the code would be a bit cleaner if we would use t->flags |= ZBX_TASK_FLAG_FOREGROUND directly instead of foreground = 1, whose sole purpose is to set t->flags = ZBX_TASK_FLAG_FOREGROUND later.

wiper RESOLVED in r57622

asaveljevs There was a superfluous "break" statement, fixed in r57644. Still RESOLVED.

wiper Thanks, CLOSED

(5) Please review minor fixes in r57436 and r57448. In particular, it fixes a declaration bug in include/log.h and removes the unnecessary ZBX_OPTION_LOGTYPE_UNDEFINED.

wiper Thanks, CLOSED

(6) Configuration files for all daemons on all platforms currently include the following section:

### Option: LogType
#	Specifies where log messages are written to:
#		syslog  - system log (syslog on Unix like systems, event log on Windows)
#		file    - file specified with LogFile parameter
#		console - console terminal
#
# Mandatory: no
# Default:
# LogType=file

How about we rename "syslog" to "system" and only mention syslog on Unix (zabbix_agentd.conf, zabbix_proxy.conf, zabbix_server.conf) and event log on Windows (zabbix_agentd.win.conf)?

asaveljevs It may also be nice to change "console terminal" to "standard output".

wiper RESOLVED in r57498

asaveljevs Windows agent logs not only to standard output, but to standard error, too. Therefore, Windows configuration file should mention standard error as well. REOPENED.

wiper RESOLVED in r57624

asaveljevs Actually, Windows seems to support dup2(), so we can redirect stderr to stdout: see https://msdn.microsoft.com/en-us/library/8syseb29.aspx . REOPENED.

wiper RESOLVED in r57649

asaveljevs Please review r57655.

wiper Thanks, CLOSED

(7) If the agent is started in foreground and its logging is set to "console", it logs the starting message twice:

$ sbin/zabbix_agentd --foreground
Starting Zabbix Agent [Zabbix server]. Zabbix 3.0.0alpha6 (revision {ZABBIX_REVISION}).
Press Ctrl+C to exit.

 26969:20160106:153817.419 Starting Zabbix Agent [Zabbix server]. Zabbix 3.0.0alpha6 (revision {ZABBIX_REVISION}).
 26969:20160106:153817.419 **** Enabled features ****
 26969:20160106:153817.419 TLS support:           YES
 26969:20160106:153817.419 **************************
 ...

Was this intended?

wiper Yes, we discussed not printing the first log record if application has been started in forgeround with console logging enabled. The decision was to keep the code simple and have it printed twice.

asaveljevs OK, CLOSED.

(8) If a daemon is running in foreground, it will probably be a bit hard to send it runtime control signals (like changing the logging level). There are two reasons for it.

The first reason is that it does not create a PID file when running in foreground, so the signal-sending binary does not know where to find the daemon.

The second reason is that the signal-sending binary cannot be run with the same configuration file in some cases:

$ sbin/zabbix_agentd -R log_level_increase
zabbix_agentd [27033]: ERROR: "LogType" 'console' parameter can be used only with --foreground command line option
$ sbin/zabbix_agentd -R log_level_increase --foreground
zabbix_agentd [27035]: foreground option can be used only when running Zabbix agent

This seems like a blocker in the design.

wiper RESOLVED in r57499

asaveljevs If Zabbix daemon is running with in foreground, then -R command is currently required to also be in foreground. It does not seem to be necessary. REOPENED.

wiper It happens when LogType is set to console. We probably should drop the foreground requirement for LogType console if we aren't starting daemon/service.
RESOLVED in r57625

asaveljevs CLOSED

(9) When a foreground process is interrupted with Ctrl+C, it is sent SIGINT signal, rather then SIGTERM as was usual before. Should we add a handling of SIGINT to lock_log() and zbx_child_fork()?

wiper definitely. Not sure about zbx_child_fork(), but we could easily get lockup on exit because of logging.

wiper RESOLVED in r57493

asaveljevs CLOSED

(10) Error messages in zbx_validate_log_parameters() are similar to those in zbx_tls_validation_error(), but are a bit different. Shall we unify some of them?

wiper validation messages were slightly improved in r57566
RESOLVED

asaveljevs I have reverted one of the messages in r57588 (see (11)), because I did not find it consistent with zbx_tls_validation_error(), but it was already consistent with messages elsewhere in server.c and proxy.c. CLOSED.

(11) Please review r57588. These are mostly consistency changes during code review.

asaveljevs r57590 changes "Run application in foreground" to "Run Zabbix agent in foreground". We do not seem to call Zabbix an application.

asaveljevs r57594 fixes one of the Windows startup messages.

wiper Thanks, CLOSED

(12) When a Windows agent logs to the console, it sometimes looks like the following:

  3092:20160113:142149.635 Starting Zabbix Agent [ZBXNEXT-611 Windows]. Zabbix 3.0.0alpha6 (revision 10000).
  3092:20160113:142149.635 **** Enabled features ****
  3092:20160113:142149.635 IPv6 support:          YES
  3092:20160113:142149.635 TLS support:            NO
  3092:20160113:142149.635 **************************
  3092:20160113:142149.635 using configuration file: c:\zabbix_agentd.conf
  3092:20160113:142149.650 agent #0 started [main process]
  6092:20160113:142149.650 agent #1 started [collector]
  5688:20160113:142149.650 agent #2 started [listener #1]  4952:20160113:142149.650 agent #3 started [active checks #1]

  4952:20160113:142150.681 active check configuration update from [192.168.1.2:10051] started to fail (cannot connect to [[192.168.1.2]:10051]: Conn
ection refused.)

It can be seen that "agent #2 started" and "agent #3 started" are on the same line. It should not be like so.

wiper RESOLVED in r57629

asaveljevs Mutex was not destroyed for LOG_TYPE_CONSOLE, fixed that in r57645. Still RESOLVED.

wiper Thanks, CLOSED

Is a backport to 2.4 possible ?

Even having 2.4 pacthes attached here, I don't see any mentions to 2.4 versions on the details of this issue.

(13) Currently, if LogType is not "file", then it complains about the presence of LogFile parameter. In TLS validation (see (86) in ZBXNEXT-1263), we do not complain about the presence of PSK parameters if, say, TLSConnect=cert and TLSAccept=cert. For consistency, it should probably be the same here to allow easy experimenting.

wiper RESOLVED in r57626

asaveljevs CLOSED

this is highly unlikely to be backported to 2.4

(14) Some programs like "ls" provide "--color" option:

      --color[=WHEN]         colorize the output; WHEN can be 'never', 'auto',
                               or 'always' (the default); more info below

Using color to distinguish file types is disabled both by default and
with --color=never.  With --color=auto, ls emits color codes only when
standard output is connected to a terminal.  The LS_COLORS environment
variable can change the settings.  Use the dircolors command to set it.

We can do similarly and only output the following message if we are connected to a user-controlled terminal:

if (0 != (flags & ZBX_TASK_FLAG_FOREGROUND))
{
	printf("Starting Zabbix Server. Zabbix %s (revision %s).\nPress Ctrl+C to exit.\n\n",
			ZABBIX_VERSION, ZABBIX_REVISION);
}

We may, however, create a separate ZBXNEXT for it.

wiper We could also colorize console logging.

asaveljevs Created a new feature request: ZBXNEXT-3098. CLOSED.

(15) Regarding stdout,stderr redirection for logging in file on Windows:

asaveljevs Function open() is now used on Windows, which is deprecated. As you suggested, we should probably use zbx_open() there to handle Unicode file names.

wiper As it turns out we are still using fopen() when opening log file. It should be also converted to _wfopen(). Maybe we should open new ZBX?

wiper Opened new issue ZBXNEXT-3097
CLOSED

(16) With running processes in foreground, it is now tempting to stop the process using "Ctrl+Z". If we then type "fg" to bring the process into foreground again, it crashes:

$ sbin/zabbix_agentd -f
Starting Zabbix Agent [Zabbix server]. Zabbix 3.0.0alpha6 (revision {ZABBIX_REVISION}).
Press Ctrl+C to exit.

 13560:20160114:160602.281 Starting Zabbix Agent [Zabbix server]. Zabbix 3.0.0alpha6 (revision {ZABBIX_REVISION}).
 13560:20160114:160602.281 **** Enabled features ****
 13560:20160114:160602.281 IPv6 support:           NO
 13560:20160114:160602.281 TLS support:            NO
 13560:20160114:160602.281 **************************
 13560:20160114:160602.281 using configuration file: /home/asaveljevs/projects/zabbix-bin/etc/zabbix_agentd.conf
 13560:20160114:160602.281 agent #0 started [main process]
 13561:20160114:160602.282 agent #1 started [collector]
 13562:20160114:160602.282 agent #2 started [listener #1]
 13563:20160114:160602.282 agent #3 started [listener #2]
 13564:20160114:160602.282 agent #4 started [listener #3]
 13565:20160114:160602.282 agent #5 started [active checks #1]
 13565:20160114:160602.282 active check configuration update from [127.0.0.1:10051] started to fail (cannot connect to [[127.0.0.1]:10051]: [111] Connection refused)
^Z
[1]+  Stopped                 sbin/zabbix_agentd -f
$ fg
sbin/zabbix_agentd -f
 13560:20160114:160604.135 One child process died (PID:13565,exitcode/signal:20). Exiting ...
 13560:20160114:160604.136 Zabbix Agent stopped. Zabbix 3.0.0alpha6 (revision {ZABBIX_REVISION}).

It also crashes if we type "bg" to put it into background or if we send a runtime control signal when the agent is sleeping.

wiper RESOLVED in r57661

asaveljevs Looks plausible and seems to work on newer versions of Linux. See issues below for other platforms. CLOSED.

wiper Actually there is a better way to do. REOPENED & RESOLVED in r57672

asaveljevs Using SA_NOCLDSTOP seems to be a bit more standard than CLD_STOPPED and CLD_CONTINUED indeed. CLOSED.

(17) Please take a look at r57659. It removes the outdated #ifdef DEBUG from log.c.

wiper CLOSED

(18) On Linux 2.4, if we run the agent in foreground and Ctrl+C it, then there is some error on child waiting:

 10908:20160117:134120.103 Got signal [signal:2(SIGINT),sender_pid:0,sender_uid:0,reason:128]. Exiting ...
 10910:20160117:134120.104 Got signal [signal:2(SIGINT),sender_pid:0,sender_uid:0,reason:128]. Exiting ...
 10909:20160117:134120.104 Got signal [signal:2(SIGINT),sender_pid:0,sender_uid:0,reason:128]. Exiting ...
 10911:20160117:134120.105 Got signal [signal:2(SIGINT),sender_pid:0,sender_uid:0,reason:128]. Exiting ...
 10912:20160117:134120.105 Got signal [signal:2(SIGINT),sender_pid:0,sender_uid:0,reason:128]. Exiting ...
 10907:20160117:134120.106 One child process died (PID:10908,exitcode/signal:1). Exiting ...
zabbix_agentd [10907]: Error on thread waiting.
 10907:20160117:134120.106 Zabbix Agent stopped. Zabbix 3.0.0alpha6 (revision 57661).

If we run the agent in background, this does not happen.

wiper RESOLVED in r57694

asaveljevs ... by ignoring SIGINT for child processes. The assumption is that SIGINT will only be sent from the terminal, which is the expected way of using that signal.

asaveljevs Added PID to the "Error on thread waiting" in r57695. Hid log lines about ignoring SIGINT in r57696. Please take a look.

wiper Thanks! CLOSED

(19) It does not compile on NetBSD 5.0:

sighandler.c: In function 'child_signal_handler':
sighandler.c:128: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token
sighandler.c:128: error: expected expression before '.' token
sighandler.c:144: error: '_info' undeclared (first use in this function)
sighandler.c:144: error: (Each undeclared identifier is reported only once
sighandler.c:144: error: for each function it appears in.)
sighandler.c:146: error: expected expression before '/' token

wiper RESOLVED in r57667

asaveljevs CLOSED

Released in:

• pre-3.0.0beta1 57722

(20) Documentation:

• what's new:
  • running zabbix daemons in foreground
• upgrade notes:
  • changes in configuration parameters related to logging
  • runnig windwos agent in console mode
• daemon configuration:
  • server
  • proxy
  • agent (nix)
  • agent (win)
• man pages
  • zabbix_agentd
  • zabbix_proxy
  • zabbix_server

RESOLVED

asaveljevs Shouldn't the changes in running zabbix daemons in foreground go under "Daemon improvements"? Also, it has one long dash before "foreground" instead of two dashes. Word "LogType" seems misformatted.

wiper It's a new feature - so I was thinking it should go in a separate section.

asaveljevs Fixed a typo in https://www.zabbix.com/documentation/3.0/manual/installation/upgrade_notes_300#changes_in_configuration_parameters_related_to_logging .

asaveljevs Let's fix bolding on daemon configuration pages: possible values for LogType are bolded, possible values for TLSConnect are not. In some places 2.4.0 and 3.0.0 are bolded, in some are not. LogFile is monoscaped, other parameter references are not. REOPENED.

wiper Removed formatting from version numbers, LogType. Replaced bold formatting with italic to LogType values. Added italic formatting to TLSConnect values.
RESOLVED

asaveljevs Made values italic for TLSAccept, too. Still RESOLVED.

wiper CLOSED

Was it intentional that usage: does not provide information on the new option?