Re: [systemd-devel] Trouble building v225 on Ubuntu 15.10
Thanks Martin, that did it. The end goal is to get systemd (mainly for sd-bus) cross-compiling for a proprietary embedded (Linux) environment that I work on. Getting it compiling on my Ubuntu laptop seemed like a good first step. -Tabor On Wed, Dec 16, 2015 at 9:16 PM, Martin Pitt wrote: > Hello Tabor, > > Tabor Kelly [2015-12-16 20:34 -0800]: >> I'm trying to get systemd v225 building on Ubuntu 15.10. When I run >> autogen.sh I get the following output: >> >> configure.ac:686: warning: macro 'AM_PATH_LIBGCRYPT' not found in library > > Missing libgcrypt20-dev. It's easiest if you just do > > sudo apt-get build-dep systemd > > to install all build dependencies of systemd than trying to discover > them one by one. > > Martin > -- > Martin Pitt| http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Trouble building v225 on Ubuntu 15.10
Hello Tabor, Tabor Kelly [2015-12-16 20:34 -0800]: > I'm trying to get systemd v225 building on Ubuntu 15.10. When I run > autogen.sh I get the following output: > > configure.ac:686: warning: macro 'AM_PATH_LIBGCRYPT' not found in library Missing libgcrypt20-dev. It's easiest if you just do sudo apt-get build-dep systemd to install all build dependencies of systemd than trying to discover them one by one. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Trouble building v225 on Ubuntu 15.10
Hello, I'm trying to get systemd v225 building on Ubuntu 15.10. When I run autogen.sh I get the following output: configure.ac:686: warning: macro 'AM_PATH_LIBGCRYPT' not found in library libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'. libtoolize: linking file `build-aux/ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: linking file `m4/libtool.m4' libtoolize: linking file `m4/ltoptions.m4' libtoolize: linking file `m4/ltsugar.m4' libtoolize: linking file `m4/ltversion.m4' libtoolize: linking file `m4/lt~obsolete.m4' configure.ac:686: warning: macro 'AM_PATH_LIBGCRYPT' not found in library configure.ac:49: error: possibly undefined macro: AC_MSG_ERROR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:686: error: possibly undefined macro: AM_PATH_LIBGCRYPT autoreconf: /usr/bin/autoconf failed with exit status: 1 I have the following versions of various required libraries and tools (installed as Ubuntu packages): glibc - 2.21 libcap - 1.7.4 libmount/util-linux - 2.26.2 pkg-config - 0.28 docbook-xsl - 1.78.1 xsltproc - 1.1.28 automake - 1.15 autoconf - 2.69 libtool - 2.4.2 intltool - 0.51.0 gperf - 3.0.4 Any input would be greatly appreciated. Thanks, Tabor ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] In OnFailure, the result is always "signal" unless KillMode=none
Resending, sans HTML... Hi, I have the script run by an OnFailure unit to send some data over the network, including whether the failure was due to a crash or watchdog timeout (I'm using WatchdogSec and sd_notify()). I use "systemctl show %i --property=ActiveStatus,Result" to retrieve what happened. However, I always get "signal". It seems that the kill gets sent before OnFailure runs. Once I set KillMode=none, then if it's a watchdog timeout, I do get Result to be "watchdog" so that's a workaround. The problem with that workaround is that if I set KillMode=none, I have to now kill the process in the script the OnFailure unit runs. This introduces races with systemctl start and stop commands being sent by another process that does complex scheduling--because now the service can be in a failed state while the process has not been killed, and a systemctl start received in that time window will cause a new instance of the process to start before the old one has been killed, which is a problem in my application. So is there any way to have it both ways, having KillMode kill the process but also being able to know whether failure was due to the process hanging vs crashing, without having to parse the journal? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] In OnFailure, the result is always "signal" unless KillMode=none
Hi, I have the script run by an OnFailure unit to send some data over the network, including whether the failure was due to a crash or watchdog timeout (I'm using WatchdogSec and sd_notify()). I use "systemctl show %i --property=ActiveStatus,Result" to retrieve what happened. However, I always get "signal". It seems that the kill gets sent before OnFailure runs. Once I set KillMode=none, then if it's a watchdog timeout, I do get Result to be "watchdog" so that's a workaround.The problem with that workaround is that if I set KillMode=none, I have to now kill the process in the script the OnFailure unit runs. This introduces races with systemctl start and stop commands being sent by another process that does complex scheduling--because now the service can be in a failed state while the process has not been killed, and a systemctl start received in that time window will cause a new instance of the process to start before the old one has been killed, which is a problem in my application. So is there any way to have it both ways, having KillMode kill the process but also being able to know whether failure was due to the process hanging vs crashing, without having to parse the journal? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
Am 16.12.2015 um 17:11 schrieb Simon Peeters: 2015-12-16 9:47 GMT+00:00 Reindl Harald : Why not do like normal people "normal people" - what's wrong with you? Nothing really, all systems both at my direct employer and those at our customers run perfectly fine, and everything is automated, so in our relatively small team we have more than enough time left to de some R&D on future and upcoming tech. so we do - 35 servers running Fedora and keep up-to-date from F9 to F23 while i do the development of the software running on top at the same time and one additional team member helps out and use configmanagement to put the right apache config on the right host? because i know how to configure servers and don't need handholding tools since i develop my own admin backends for many years and services helping on repeatly needed taks but don't chain me to a limited subset of the supported options If you want to use your home grown configmanagement tool, then learn it to decently manage your apache config. it does exactly what it is supposed to do and all is runnign perfectly fine as long not somebody breaks working things things by remove feautes for no good reason This whole "-D testserver" and "" looks like an ugly workaround for a lacking configmanagment system. config managements for webservers are ugly workaround for lacking knowledge and only fine for 08/15 setups but a no-go where you need flexibility I think a lot of people disagree with you on that, including most of the devops world. most of that people are using LTS distributions where you don't have major jumps - it's enough to care about major upgrades itself and i don't need the burden "does config mgmt xyz support version a of serversoftware b" for my own development not rely on any 3rd party libraries i can guarantee that there are no compatibility breaks and since that works now over nearly 15 years inclduing a complete jump from Apple to Fedora i am proven right no, i don't say you or anybody else should do it the same way, do what you want, in the area where i am responsible i do the things which are proven to work with as less complexity and dependencies as possible go away with that crap - only over my dead body besides Perl, PHP and Python now Ruby and it's dependencies would make it to any server here Then use something else, like ansible, which is python, or cfengine, or juju, or any other one in this list https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software introducing another layer of complexity on a environment which works relieable and rock stable over many years and everybody who needs to touch it understands how and why things are working as they are supposed to do would be stupid KISS - keep it simple stupid My point being if you want to manage your apache config, manage your apache config, intead of doing wierd workarounds with environment variables and changing the ExecStart of your service. In your case this is even flawed: If the /etc/sysconfig/httpd file changes, then a systemctl reload httpd wouldn't propagate the changes, while if you instead managed the config directly it would well, you are talking about a no-problem since that file changed 3 times in 8 years where a hard restart of httpd is a no-brainer just because it's more often needed after PHP, zlib, pcre and what not updates signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
2015-12-16 9:47 GMT+00:00 Reindl Harald : > > > Am 15.12.2015 um 18:59 schrieb Simon Peeters: >> >> 2015-12-10 15:20 GMT+00:00 Reindl Harald : >>> >>> >>> Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson: If you are unaware of any other use case for it >>> >>> >>> EnvironmentFile=-/etc/sysconfig/httpd >>> ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND >>> >>> [root@testserver:~]$ cat /etc/sysconfig/httpd >>> OPTIONS="-D testserver" >>> >>> Apache: >>> >>> Include "conf/local/testserver.conf" >>> >>> >>> and now you can use the same systemd-unit on a dozens of machines and >>> include specific config snippets WITOUT touch the systemd-unit or >>> *anything* >>> else in the apache configuration >>> perhaps it's time to start looking into obsoleting it >>> >>> >>> don't get me wrong but you sound once again like seek for changes to >>> break >>> users configuration to later blame users why they did not fix which ain't >>> broken >> >> >> Why not do like normal people > > > "normal people" - what's wrong with you? Nothing really, all systems both at my direct employer and those at our customers run perfectly fine, and everything is automated, so in our relatively small team we have more than enough time left to de some R&D on future and upcoming tech. >> and use configmanagement to put the >> right apache config on the right host? > > > because i know how to configure servers and don't need handholding tools > since i develop my own admin backends for many years and services helping on > repeatly needed taks but don't chain me to a limited subset of the supported > options If you want to use your home grown configmanagement tool, then learn it to decently manage your apache config. >> This whole "-D testserver" and "" looks like an >> ugly workaround for a lacking configmanagment system. > > > config managements fpr webservers are ugly workaround for lacking knowledge > and only fine for 08/15 setups but a no-go where you need flexibility I think a lot of people disagree with you on that, including most of the devops world. >> More preciesly conf/local/testserver.conf probably shouldn't even >> exist on non testing mahines > > > guess why it's in the subfolder "local" > >> '/etc/…/testserver.conf': ensure => absent }" in puppet > > > go away with that crap - only over my dead body besides Perl, PHP and Python > now Ruby and it's dependencies would make it to any server here Then use something else, like ansible, which is python, or cfengine, or juju, or any other one in this list https://en.wikipedia.org/wiki/Comparison_of_open-source_configuration_management_software My point being if you want to manage your apache config, manage your apache config, intead of doing wierd workarounds with environment variables and changing the ExecStart of your service. In your case this is even flawed: If the /etc/sysconfig/httpd file changes, then a systemctl reload httpd wouldn't propagate the changes, while if you instead managed the config directly it would. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
Am 15.12.2015 um 18:59 schrieb Simon Peeters: 2015-12-10 15:20 GMT+00:00 Reindl Harald : Am 10.12.2015 um 15:46 schrieb Jóhann B. Guðmundsson: If you are unaware of any other use case for it EnvironmentFile=-/etc/sysconfig/httpd ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND [root@testserver:~]$ cat /etc/sysconfig/httpd OPTIONS="-D testserver" Apache: Include "conf/local/testserver.conf" and now you can use the same systemd-unit on a dozens of machines and include specific config snippets WITOUT touch the systemd-unit or *anything* else in the apache configuration perhaps it's time to start looking into obsoleting it don't get me wrong but you sound once again like seek for changes to break users configuration to later blame users why they did not fix which ain't broken Why not do like normal people "normal people" - what's wrong with you? and use configmanagement to put the right apache config on the right host? because i know how to configure servers and don't need handholding tools since i develop my own admin backends for many years and services helping on repeatly needed taks but don't chain me to a limited subset of the supported options This whole "-D testserver" and "" looks like an ugly workaround for a lacking configmanagment system. config managements fpr webservers are ugly workaround for lacking knowledge and only fine for 08/15 setups but a no-go where you need flexibility More preciesly conf/local/testserver.conf probably shouldn't even exist on non testing mahines guess why it's in the subfolder "local" '/etc/…/testserver.conf': ensure => absent }" in puppet go away with that crap - only over my dead body besides Perl, PHP and Python now Ruby and it's dependencies would make it to any server here signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
