Re: [systemd-devel] systemd-networkd on by default?
Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek: On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files) that is a bad reasoning not a single process should be running if it has no job to do for the sake of ressource usage, security and clean systems 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] systemd-networkd on by default?
Am 21.02.2014 16:44, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 21/02/14 08:45 did gyre and gimble: Am 21.02.2014 04:41, schrieb Zbigniew Jędrzejewski-Szmek: On Fri, Feb 21, 2014 at 04:00:10AM +0100, Jason A. Donenfeld wrote: systemd-networkd seems to get started by default in 209. Why is this? What if I don't want to use it to manage my networks? Why does it have to be on by default? I think the reasoning was that it doesn't do anything by default (when there are no configuration files) that is a bad reasoning not a single process should be running if it has no job to do for the sake of ressource usage, security and clean systems Well I kinda get that using it for containers and such like could be useful, but I also suspect it should be bus or socket activated rather than statically enabled... like localed, datetimed etc. Any reason to enable it statically? (I guess it maybe has to do stuff by itself, but I would figure udev should kick it in via the setup link built in in most cases - but I guess that wouldn't work inside containers, so perhaps this is where things break down and you need it statically enabled) statically enabled is bad in general, containers are not a good reason to enable something for everybody, many if not most people never will use containers for several reasons and if it because they use full-virtualization and move machines between different also non-linux hosts where i would support something new enabled by default is if could *replace* something else like LSB network.service while use it's ifcfg-configurations for backward compatibility and test out if it really can replace all cases if i can replace that below i start to be one of the first production users in a complexer setup (one is the MAC of the physical card, the other is what it becames before fetch the IP from the ISP because you need to register your MAC there, that's the same like MAC cloning in small soho-routers) DEVICE=eth1 HWADDR=68:05:ca:0d:62:c1 ONBOOT=yes BOOTPROTO=dhcp IPV6INIT=no NM_CONTROLLED=no USERCTL=no PEERDNS=no MACADDR=00:50:8d:b5:cc:de but something hanging around unconfigured please no 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] Forwarding logs to another systems journal
Am 13.03.2014 20:54, schrieb Anand Neeli: I have multiple systems, How do i forward logs from one system running systemd-journald to another remote systems journal service, so that all the logs are stored on a centralized machine. that's not the job of journald and falls into the use-case of continue with rsyslog which happily receives the log from systemd-journald 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] How to manually set service in failed state
Am 18.03.2014 22:59, schrieb Usman: I am trying to test some code with respect to my services setup. I have two services, lets say service_a and service_b. In service_a unit file I have this: OnFailure=service_b And from the man page for OnFailure unit I get this: A space-separated list of one or more units that are activated when this unit enters the failed state My question is, to test this setup, how can I have service_a in a failed state? I have tried using kill -9, but that leaves service in signal state and not failed state. How can I manually set a service in failed state so that service_b gets started for my testing? Any specific signal? Any help much appreciated. kill -4 http://www.linux.org/threads/kill-commands-and-signals.4423/ SIGILL - When a process performs a faulty, forbidden, or unknown function, the system sends the SIGILL signal to the process. This is the ILLegal SIGnal 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 64) SIGRTMAX 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] Building systemd from git
Am 20.03.2014 15:02, schrieb Kevin Wilson: --prefix etc. I assume you mean: --prefix /etc and not prefix /etc is it so ? KW no: http://en.wikipedia.org/wiki/Et_cetera you don't want your binary tree in /etc On Wed, Mar 19, 2014 at 10:44 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Mar 19, 2014 at 10:25:30PM +0200, Kevin Wilson wrote: Hello, When I build systemd from git using the usual procedure of configure, without setting special parameters, it installs folder under /usr/etc/systemd/ (like /usr/etc/systemd/system and its children, /usr/etc/systemd/network/, and more). That's the usual GNU style. Is there a way to run configure so that, instead of /usr/etc/systemd/, it will use /etc/systemd/ ? In Fedora, for example, the rpm uses the /etc/systemd and not /usr/etc/systemd/, which does not exist. Use --prefix etc. Look ./autogen.sh for some nice default options 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] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
Am 12.02.2014 21:19, schrieb Lennart Poettering: On Wed, 12.02.14 20:05, Reindl Harald (h.rei...@thelounge.net) wrote: maybe systemd-upstream should consider slow down development and spend more energy in quality and stability Well, firstly, it's hardly your business how we spend our time looks like it's also not Linus business http://www.spinics.net/lists/kernel/msg1716484.html __ From: Linus Torvalds torvalds@ Date: Wed, 2 Apr 2014 16:13:27 -0700 It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem. 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] [PATCH v4] use systemd.debug on the kernel command line, not debug
Am 05.04.2014 23:22, schrieb Zbigniew Jędrzejewski-Szmek: The whole issue started with bug #76935: the original reporter was seemingly unaware of available kernel commandline options, and his comments fairly quickly degenerated to rude personal attacks. It's something that one sees quite often: a complaint, a reply how requested goals can be achieved and why things are implemented the way they are, followed by demands of having it my way, followed by a fit and swearing. Then come Anonymous Helpers. I really don't see why we should deal with this shit and waste time on people who evidently want to vent their frustration rather than solve a bug. cause and effect, the rude attacks maybe because ignorance and frustration about the we are always right attitude what makes sense *to you* is not the only relevant thing! http://lkml.org/lkml/2012/10/3/484 http://www.spinics.net/lists/kernel/msg1716484.html https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF i guess Kay will now remove me from that list because as affected user i have to shut up in general but that does not change anything in casue and effect and that there are enough people with zero understanding for I really don't see why we should deal with this shit which is your userbase - if you are not interested in users you should make a private project but not the first most imporant piece after the kernel because that brings *responsibility* ___ no other software than systemd logs that much to *bury* any for a non-systemd-developer relevant infos even under normal operations http://www.spinics.net/lists/kernel/msg1716484.html Linus words I personally find it annoying that it's always the same f*cking primadonna involved are hardly because *that one* thing and should lead to consider things are handeled wrong instead continue with I really don't see why we should deal with this shit the following parapgraph talks also about a general attitude that anybody with critism is treated as enemy all the time and everything left and right of systemd is broken in general and has to be fixed because it stands in the way of systemd It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem. 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] Systemd 212 RemoveIPC=yes breaks postgresql
Am 11.04.2014 03:01, schrieb Lennart Poettering: Tradditionally on Linux this is done via login.defs, but I am really not convinced this should be runtime configurable. I'd prefer to detect the minimal normal UID at compile time, and then use that to distuingish normal from system users please don't hardcode such things Fedora has for many realeases 1000 [root@srv-rhsoft:~]$ cat /etc/login.defs | grep UID_MIN UID_MIN 500 that's just why configuration exists and how it looks after many dist-upgrades chnage that not doable in case one has to maintain dozens of machines where from day one every admin took care that all users have identical ID's and LDAP is not a topic in case you have a virtual infrastructure with cloned guests in different network segments - so the change UID_MIN to 1000 won't happen there 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] [PATCH] timer: allow user to control activation time of cron-like timers
Am 11.05.2014 18:30, schrieb Alex B: 2014-05-11 20:09 GMT+04:00 Dave Reisner d...@falconindy.com: On Sun, May 11, 2014 at 07:53:55PM +0400, Alexander Bashmakov wrote: Issue was rised in this thread: https://mailman.archlinux.org/pipermail/arch-general/2014-May/036162.html Disclaimer: I almost have no expereince in C. So this patch can contain some silly mistakes. But it 'works for me'. Please consider it as RFC. -8--- Cron-like timers are useful for maintenance tasks and already used in some distros by default. But midnight is not best time for this. Just add a new option allowing user to specify activation time (and date) for such timers globally. daily is just syntactic sugar for *-*-* 00:00:00. If you don't want to run at midnight, modify the normalized form to run at the time you want. It's ok for one timer, but not for the set of them. In general I'm want to schedule all maintenance tasks to 5 a.m. or lunch break and forget about them. This applies both for distro provided timers an my own that's why anacron don't fire up them at the same time given that you can have on a host 10,20,100 guests *that* below is the solution __ # /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/usr/bin/bash PATH=/usr/bin:/usr/sbin LANG=en_GB.UTF-8 MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=5 # the jobs will be started during the following hours only START_HOURS_RANGE=3-9 #period in days delay in minutes job-identifier command 1 5 cron.daily nice -n 19 run-parts /etc/cron.daily 7 25 cron.weekly nice -n 19 run-parts /etc/cron.weekly @monthly 35 cron.monthly nice -n 19 run-parts /etc/cron.monthly 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] [PATCH] build: Honour SUID_CFLAGS and SUID_LDFLAGS
Am 17.05.2014 22:02, schrieb Cristian Rodríguez: El 17/05/14 14:56, Dave Reisner escribió: On Sat, May 17, 2014 at 12:39:47PM -0400, Cristian Rodríguez wrote: This is the standard* way used to pass special linker/compiler flags such as -fPIE and -pie * Standard in the sense it is understood by many other packages and commonly used by distributions. This doesn't really make sense to me. I infer from the names of the variables that these are flags passed to the compiler for binaries which will eventually be setuid root. That was the initial purpose of this variable, yes. Currently is just to provide a separate variable for hardened builds. Note that I did not came up with this idea, It is just the way things are done elsewhere, where elsewhere is util-linux, policykit, various gnome components,enlightment,samba etc.. IMHO these days *anything* should be build as PIE the performance impact on x86_64 is low to zero 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] [PATCH 17/17] networkd: add dhcp server support
Am 27.05.2014 20:14, schrieb Kirill Elagin: The container usecase alone is already the reason why I am so very sure I want this stuff, and that it needs to be in networkd, and just work. I want this fully automatic, so that we can create a hundred of veth tunnels, and trivially easy (simply by setting DHCPServer=yes for their .network file) make them automatically configured, passing the relevant configuration bits on. I'm sorry to intervene, but there are other ways to configure containers and similar stuff. I mean, systemd is great because it pioneered so many cool things. Why can't we do something new? For example, prohibit IPv4 for containers and VMs and require them to use IPv6 with link-local addresses which will eliminate the need for any kind of configuration. Pushing IPv6 forward is a good idea. But, well, if you find this unacceptable, what's wrong with IPv4LL? because people are using containers to reflect the real life out there? that means IPv4 for a very very long time that means *dual stack* for a very very long time how do you imagine building up a comlex network structure within containers for simulations and after figure out things take them for production and only replace the network segments? if someone starts with something new followed by prohibit things which are just in use and working he only can be wrong 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] Delaying (SSH) key generation until the urandom pool is initialized
Am 06.06.2014 11:50, schrieb Florian Weimer: On 05/05/2014 04:35 PM, Lennart Poettering wrote: Hmm? Well, a virtualized OS has to trust the hypervisor, there's no way around that. I'm referring to this: * This function will use the architecture-specific hardware random * number generator if it is available. The arch-specific hw RNG will * almost certainly be faster than what we can do in software, but it * is impossible to verify that it is implemented securely (as * opposed, to, say, the AES encryption of a sequence number using a * key known by the NSA). So it's useful if we need the speed, but * only if we're willing to trust the hardware manufacturer not to * have put in a back door. I think this is the reason why the pool isn't considered initialized even if its contents has been randomized with RDRAND or similar instructions. I wouldn't be surprised if these minds have a similar concern about randomness coming from a hypervisor if you don't trust the underlying hardware and hypervisor you are lost in any case, that's a battle you can't win and in that context the random numbers are your smallest problem at all 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] Restart best practices
Am 06.06.2014 11:48, schrieb Jóhann B. Guðmundsson: On 06/05/2014 05:00 PM, Lennart Poettering wrote: I think it would make sense to recommend that packagers and upstream packages adopt Restart=on-failure or Restart=on-abnormal (where the former is not appropriate) for all long-running daemons. However, this recommendation should be taken with a grain of salt, as for some services it might be a bad choice to just tape over problems and restarting it again on failure... Hence, this is really not something to blindly apply to all services on the world, but just a recommendation that individually should be considered. We already have units in the wild upstream where the internet has effectively spread ignorance once again which contain Restart=Always when they should not where do you see ignorance here? if there is running a service which should always run the only valid reason it's main process is stopped is a systemctop stop whatever.service for any long running service like web/mail/database servers Restart=always is what i expect as admin signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] no fsck at boot
touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Jun 8 14:51:31 localhost systemd-fsck[349]: system: sauber, 31614/640848 Dateien, 390558/2559727 Blöcke Jun 8 14:51:31 localhost kernel: [4.855832] EXT4-fs (md127): warning: checktime reached, running e2fsck is recommended Jun 8 14:51:31 localhost kernel: [5.975985] EXT4-fs (md126): warning: checktime reached, running e2fsck is recommended Jun 8 14:51:31 localhost kernel: [6.632882] EXT4-fs (md125): warning: checktime reached, running e2fsck is recommended tune2fs -l /dev/md127 tune2fs 1.42.7 (21-Jan-2013) Filesystem volume name: system Last mounted on: / Filesystem UUID: 22f62744-8fd7-4090-aff8-b35ef38b4b74 Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options:user_xattr acl nobarrier Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 640848 Block count: 2559727 Reserved block count: 25597 Free blocks: 2169169 Free inodes: 609234 First block: 0 Block size: 4096 Fragment size:4096 Reserved GDT blocks: 624 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8112 Inode blocks per group: 507 Flex block group size:16 Filesystem created: Mon Mar 19 13:48:13 2012 Last mount time: Sun Jun 8 14:51:19 2014 Last write time: Sun Jun 8 14:51:19 2014 Mount count: 21 Maximum mount count: -1 Last checked: Mon Nov 25 20:45:49 2013 Check interval: 15552000 (6 months) Next check after: Sat May 24 21:45:49 2014 Lifetime writes: 178 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode:8 Default directory hash: half_md4 Directory Hash Seed: bea48679-30ba-4a71-82d9-d4b2fe0a80b8 Journal backup: inode blocks 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] no fsck at boot
Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all 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] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 17:28, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote: Date: Mon, 09 Jun 2014 10:48:31 +0300 From: Leho Kraav l...@kraav.com To: Reindl Harald h.rei...@thelounge.net, systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to quiet cron sessions logging with systemd-212? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 On 09.06.2014 10:43, Reindl Harald wrote: nobody cares because the developers point of view is that what is interesting for them needs to be also faced by the sysadmin otherwise this would be only logged in debug-mode and bugreports not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 frankly if that messages would at least have a prefix or a different process than systemd one could filter them out with rsyslog.conf without supress relevant boot messages Thanks for the info. I tried googling for this relatively hard, couldn't find that bug. Language on that bug is probably counterproductive, but other than that, some reasonably sensible way should exist to simply stop logging crap, not relying on just output filtering. What you see are authpriv-level logs, so it would be a really bad idea to suppress them, regardless of their source no user needs them, there are already logs which command was started for which user from crond with just 3 lines Jun 9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly) Jun 9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron Jun 9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron Jun 9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly) Jun 9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron Jun 9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron they are introduced in that floody way with recent systemd all the decades before crond did run fine, logs exactly what you need to know if /var/log/secure and /var/log/crond without writing *hundret thousands* loglines all day long on machines with a lot of cronjobs 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] no fsck at boot
Am 09.06.2014 21:26, schrieb Alexander E. Patrakov: 10.06.2014 00:57, Reindl Harald wrote: Am 09.06.2014 20:45, schrieb Alexander E. Patrakov: 10.06.2014 00:04, Reindl Harald wrote: Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all Please paste your /etc/fstab file. If it has 0 0 as the last two fields, then, of course, systemd will not call fsck. If there are different numbers there, sure, let's debug. Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem go away if you regenerate your initramfs? i know how to deal with fstab and column 6 is not zero as well as the initramfs is regenrated all the time because kernel updates which are *the reason* for reboots on servers at all what disturbs me is they warning about touch /forcefsck while it's currently the *only* option to trigger a recommended fsck at boot on a remote-server (and no add kernel params for that in the grub-config and remove them after is not a sane way for sysadmins maintaining 10,20,30 remote servers) UUID=209aeed4-95bd-4eb0-bdfa-fb346b603ce9 /boot ext4 defaults 0 1 UUID=22f62744-8fd7-4090-aff8-b35ef38b4b74 / ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota 0 1 UUID=0b95905b-02c5-444b-af9e-7615cabebb38 /mnt/data ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota,nosuid 0 2 OK. Let's try eliminating some more reasons why fsck can be skipped. 1. The root filesystem is mounted read-write at boot [but note that this doesn't explain failures to check other filesystems] 2. The generator did not run for some unknown reason. 3. Some other error that got hopefully logged. Could you please attach the output of: ls -lR /run/systemd/generator journalctl -b Also, could you please try replacing some non-critical UUID=... lines (e.g. for /boot) in your fstab by direct device references of the form /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9 or even /dev/mdX, just to see if that's UUID who triggers the bug for you? To avoid getting an inaccessible server if that misfires, you can also append nofail to the options for /boot systemd even pretends it does the fsck, i have nothing more to say on that topic except remove the deprecation warning and output the volume-label at least additionally to the UUID [root@localhost:~]$ journalctl -b | grep File System Jun 08 14:51:15 localhost systemd[1]: Starting Local File Systems. Jun 08 14:51:15 localhost systemd[1]: Reached target Local File Systems. Jun 08 14:51:16 localhost systemd[1]: Starting Initrd Root File System. Jun 08 14:51:16 localhost systemd[1]: Reached target Initrd Root File System. Jun 08 14:51:16 localhost systemd[1]: Starting Initrd File Systems. Jun 08 14:51:16 localhost systemd[1]: Reached target Initrd File Systems. Jun 08 14:51:19 localhost systemd[1]: Started File System Check on Root Device. Jun 08 14:51:19 localhost systemd[1]: Starting Remount Root and Kernel File Systems... Jun 08 14:51:19 localhost systemd[1]: Started Remount Root and Kernel File Systems. Jun 08 14:51:19 localhost systemd[1]: Starting Local File Systems (Pre). Jun 08 14:51:19 localhost systemd[1]: Reached target Local File Systems (Pre). Jun 08 14:51:20 localhost systemd[1]: Starting File System Check on /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9... Jun 08 14:51:20 localhost systemd[1]: Started File System Check on /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9. Jun 08 14:51:20 localhost systemd[1]: Starting File System Check on /dev/disk/by-uuid/0b95905b-02c5-444b-af9e-7615cabebb38... Jun 08 14:51:21 localhost systemd[1]: Started File System Check on /dev/disk/by-uuid/0b95905b-02c5-444b-af9e-7615cabebb38. Jun 08 14:51:21 localhost systemd[1]: Starting Local File Systems. Jun 08 14:51:21 localhost systemd[1]: Reached target Local File Systems. [root@localhost:~]$ journalctl -b | grep e2fsck Jun 08 14:51:19 localhost kernel: EXT4-fs (md127): warning: checktime reached, running e2fsck is recommended Jun 08 14:51:20 localhost kernel: EXT4-fs (md126): warning: checktime reached, running e2fsck is recommended Jun 08 14:51:21 localhost kernel: EXT4-fs (md125): warning
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 21:07, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote: all the decades before crond did run fine, logs exactly what you need to know if /var/log/secure and /var/log/crond without writing *hundret thousands* loglines all day long on machines with a lot of cronjobs If you don't need them -- OK, but don't speak for the others. Why systemd should be treated any differently than other programs? because Lennart to ospeaks for others the way he closed that bugreport? why can't there be at least a config option to disable creating them at all? because other programs *never ever* procude *that lot* of loglines all day long - look at the simple calculation in the bugreport on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd if they would contain a unique string / prefix to distinguish from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal 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] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? if you already have logs from the daemon (cron) or a login program (login), why keep systemd-generated messages? I'd put them in a separate file... if i can put them in a seperate file i can filter them out if they would contain a unique string / prefix to distinguish Do you have something concrete in mind? systemd-user: or whatever that would also make clear the we *do not* start all sorts of targets, the flooding log in misleading anyways that below is just *not true* from the users point of view Jun 9 22:36:07 rawhide systemd[1]: Starting User Manager for UID 0... Jun 9 22:36:07 rawhide systemd[607]: Starting Paths. Jun 9 22:36:07 rawhide systemd[607]: Reached target Paths. Jun 9 22:36:07 rawhide systemd[607]: Starting Timers. Jun 9 22:36:07 rawhide systemd[607]: Reached target Timers. Jun 9 22:36:07 rawhide systemd[607]: Starting Sockets. Jun 9 22:36:07 rawhide systemd[607]: Reached target Sockets. Jun 9 22:36:07 rawhide systemd[607]: Starting Basic System. Jun 9 22:36:07 rawhide systemd[607]: Reached target Basic System. Jun 9 22:36:07 rawhide systemd[607]: Starting Default. Jun 9 22:36:07 rawhide systemd[607]: Reached target Default. Jun 9 22:36:07 rawhide systemd[607]: Startup finished in 9ms. Jun 9 22:36:07 rawhide systemd[1]: Started User Manager for UID 0. from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal If resources are an issue, don't use the journal. In my experience, it consumes ~4x space compared to syslog (on a firewall machine, after 2 months uptime)... i don't use the journal, the configuration of journald is like below the log-flood makes things even worser because it leads to early rotation and purges systemctl status whatever.service informations by purging the memory-journal if it comes to ressource usage: all that dropped messages (if you could drop/filter them) are producing data and overhead in general, only because you manage to not see things that don't mean they produce no overhead [root@rawhide ~]# cat /etc/systemd/journald.conf [Journal] Storage=volatile Compress=no RateLimitInterval=10s RateLimitBurst=500 RuntimeMaxUse=15M 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] How to quiet cron sessions logging with systemd-212?
Am 10.06.2014 12:20, schrieb Lennart Poettering: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about if things are only *sometimes* useful that means most of the time they are not and for anybody who is not a systemd-developer or debugging something they are just noise at least the enable-linger should be default because you anyways have all the disturbing sd-pam processes long running which you need to kill after updates on libraries to get anything in listed with lsof | grep DEL | grep /usr clean so don't start a complete systemd session for a simple cronjob which did his job decades before systemd existed or just don't stop it all the time the started target... messages are in *any case* misleading 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] How to quiet cron sessions logging with systemd-212?
Am 10.06.2014 18:01, schrieb Lennart Poettering: On Tue, 10.06.14 13:24, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... which is cheaper than fire up a complete session again and again with all the logs recent systemd generates and you *already* have long running processes for each user ever started a cronjob also under Fedora 20 which don't flood the logs otherwise they already annoy me a lot because the last decades that all was not there and cronjobs where just fine vmware4030 0.0 0.0 74208 2064 ?SJun08 0:00 (sd-pam) harry 4351 0.0 0.0 74208 2132 ?SJun08 0:00 (sd-pam) root 9806 0.0 0.0 74208 2208 ?SJun08 0:00 (sd-pam) wwwcron 10894 0.0 0.0 74208 2224 ?SJun08 0:00 (sd-pam) apache 10918 0.0 0.0 74208 2236 ?SJun08 0:00 (sd-pam) 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] systemd not initializing
Am 13.06.2014 16:35, schrieb Cristian Rodríguez: El 13/06/14 05:19, Jay D Bhatt escribió: Thanks. I surely forgot to attach log. Now you can find it attached. Nope, there is no attached log in your message because he sent the attachment one message before and found it useful to drop another one refer to that 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] mdns support to networkd
Am 23.06.2014 21:09, schrieb Vasiliy Tolstov: 2014-06-23 16:13 GMT+04:00 Lennart Poettering lenn...@poettering.net: Both. mDNS is a very much a peer-to-peer system, hence all participants tend to implement both sides. I actually intend to make this useful enough so that we can use it for containers and the host to discover earch other and their services. Does exists any roadmap for this? Because now with avahi i can't publish additional addresses and need to patch sources to minimize timeout from 5000msec to 1000msec. (my hosts does not have ptr records and for each ping i have 5 sec timeout =() why don't you just setup PTR records? not having so brings a lot of implications, not only avahi as example sane configured ssh-daemons won't allow to login 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] [PATCH] install: enable timesyncd by default
Am 25.06.2014 14:43, schrieb Michael Olbrich: This treats it similarly to networkd, resolved and others and it matches what 90-systemd.preset does. --- Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile.am b/Makefile.am index 4b292b2..bfef1c3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -4301,6 +4301,9 @@ rootlibexec_PROGRAMS += \ nodist_systemunit_DATA += \ units/systemd-timesyncd.service +GENERAL_ALIASES += \ + $(systemunitdir)/systemd-timesyncd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-timesyncd.service + EXTRA_DIST += \ units/systemd-timesyncd.service.in another thing to mask on virtual machines which don't rely on NTP or something else because they sync with the host-os over their guest-tools 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] xz troubles
Am 02.07.2014 02:20, schrieb Zbigniew Jędrzejewski-Szmek: this is in some sense a continuation of the subject of xz compression for coredumps. I've been benchmarking systemd-journal-remote + nc upload speed on some fake data in which the MESSAGE fields are a few kb, big enough to trigger xz compression in the journal. This is probably not a normal stream, but not a completely impossible one. The result is of sending 708 MB of logs is: - without compression, 713 MB of journal files, 23 s, - with compression, 361 MB of journal, 19 min 29 s! So the 23 seconds are not particularly impressive, I think there are some unnecessary reallocs and copies there which can be eliminated improved by implementing a sliding window. I tried to minimize the memory usage, but it seems to be hurting performance. But the 19.5 minutes is rather bad, and I think it is attributable to compression of a gazillion relatively small blobs. This could also explain why journald sometimes performes so badly. A different compressor? because XZ is a very very bad idea for such things in case of coredumps LZO/LZ4 would be the right compression XZ gives a great compression rate but it takes *very long* see also the fedora-devel thread about deltarpm in case of XZ compressed packages which are rebuilt locally and take way longer than download the whole RPM XZ is hence great for compress one time and use many times like RPM packages, logrotate where it does not matter if it takes 30 minutes in the middle of the night but should be avoided for things user tasks are waiting for 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] [PATCH] build: Honour SUID_CFLAGS and SUID_LDFLAGS
the main question is *why* is it systemd's business?
that flags are generelly set at the distribution level
and in case of Fedora they can differ between archs
because each arch has it's own %{optflags}
the whole mess exists because upstream projects
don't leave their fingers from that flags at all
Am 02.07.2014 13:52, schrieb Umut Tezduyar Lindskog:
I am agreeing with Simon. We use mips and we see the mentioned
impacts. We also see quite size difference (%6 large on systemd-cat
binary text section) which might not be so welcomed on embedded
system.
Umut
On Mon, May 19, 2014 at 12:37 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
On 18/05/14 16:47, Cristian Rodríguez wrote:
OK, Let's try [building everything -fPIE] instead.
Hopefully things have improved since 2011, but my experience with
dbus[1] has been that this works fine on mainstream architectures, but
frequently fails on embedded architectures (arm* family, mips* family,
etc.) where various toolchain versions have been known to fail to
compile, fail to link, or worse, link binaries that sometimes or always
crash at runtime (which is hard to detect in a configure script without
breaking cross-compilation).
libtool has relatively intelligent handling of the PIE compiler flags,
so if a distro wants to enable -fPIE (or other hardening options like
-Wl,-z,relro) it's easy for that distro to enable PIE by passing
appropriate CPPFLAGS, CFLAGS, LDFLAGS, etc. to the configure script,
which works for any libtool + Autoconf + Automake project without
modification:
./configure CFLAGS=-fPIE LDFLAGS=-pie
In distributions where not all architectures have the same level of
upstream toolchain support, centralizing the decision about compiler
flags to one place (e.g. dpkg-buildflags, and previously
hardening-wrapper, in Debian) means it's possible to avoid broken flag
combinations per-architecture, without having to encode that knowledge
into each package.
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] [PATCH 1/2] journal: add LZ4 as optional compressor
Am 06.07.2014 21:47, schrieb Lennart Poettering: BTW, have you checked whether reuseing the XZ context might make the XZ more competitive? please try a simple test compress 50 MB with XZ and GZ, LZO, LZ4 or BZIP2 - XZ is *magnitudes* slower in any case, there is simply nothing to optimize - XZ is the wrong compression for anything where user feedback in time matters, even with no care about memory usage which also is part of the game finally 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] [PATCH 1/2] journal: add LZ4 as optional compressor
Am 08.07.2014 12:22, schrieb Jon Severinsson: Am 06.07.2014 21:47, schrieb Lennart Poettering: BTW, have you checked whether reuseing the XZ context might make the XZ more competitive? On Sun Jul 6 15:01:11 PDT 2014 Reindl Harald wrote: please try a simple test compress 50 MB with XZ and GZ, LZO, LZ4 or BZIP2 - XZ is *magnitudes* slower in any case Actually it is not, or rather, it is only that if you want it to be that. I did a quick comparison using the systemd 214 tar (30 MiB): xz -0 was 28% slower than lz4c -hc, but the result was 19% smaller. xz -0 was even 44% faster than gzip -9, and the result was still 5% smaller. XZ is the wrong compression for anything where user feedback in time matters No, xz -6 is the wrong compression *setting* for that use-case, but at a lower setting xz is quite suitable even for that. even with no care about memory usage which also is part of the game finally xz -0 needs about 3 MiB for compression, hardly a prohibitive requirement you simply missed the benchmarks see topic compress: add benchmark-style test yesterday With 0: XZ: compressed decompressed 2535300963 bytes in 33.01s (73.25MiB/s), ... LZ4: compressed decompressed 2535303543 bytes in 1.31s (1838.75MiB/s), .. 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] [PATCH] sysusers: allow overrides in /etc and /run
Am 10.07.2014 16:59, schrieb Jóhann B. Guðmundsson:
On 07/10/2014 12:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
An administrator might want to block a certain sysusers config file from
being executed, e.g. to block the creation of a certain user.
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 129493a1e7..68c552d24a 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -62,6 +62,8 @@ typedef struct Item {
static char *arg_root = NULL;
static const char conf_file_dirs[] =
+/etc/sysusers.d\0
+/run/sysusers.d\0
/usr/local/lib/sysusers.d\0
/usr/lib/sysusers.d\0
#ifdef HAVE_SPLIT_USR
How does this handle multiple users and if I as an administrator I wanted to
block some users from being created I simply would not have installed the
component that created him in the first place no?
you sound like it is always clear what package, probably installed as
dependency creates a user before - not speaking about that most packages
due uninstall don't remove the users created in rpm scripts
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] sysusers and login.defs checks
Am 20.07.2014 23:38, schrieb Colin Guthrie: 'Twas brillig, and Colin Guthrie at 20/07/14 22:31 did gyre and gimble: Those defaults could be set from a compile time check of login.defs too. FWIW, at least here, /etc/login.defs is not readable by regular users so any build system that builds as non-root won't even get those defaults anyway, so that's probably another argument for runtime checks too... why is it not readable? [root@srv-rhsoft:~]$ rpm -q --file /etc/login.defs shadow-utils-4.1.5.1-8.fc20.x86_64 [root@srv-rhsoft:~]$ stat /etc/login.defs File: '/etc/login.defs' Size: 1475Blocks: 8 IO Block: 4096 regular file Device: 901h/2305d Inode: 1179182 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2011-08-02 14:24:16.0 +0200 Modify: 2011-08-02 14:24:16.0 +0200 Change: 2014-03-01 21:20:57.113612115 +0100 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] How to reduce systemd logging to syslog ?
Am 21.07.2014 03:10, schrieb sur...@emailengine.net: On Sun, Jul 20, 2014, at 05:31 PM, Zbigniew Jędrzejewski-Szmek wrote: 2. tell systemd to log less with 'systemd-analyze set-log-level notice'. Won't that lower the log level 'into' the journal as well? hopefully I'm happy to have that populated with a high level of detail -- I just don't want 'noisy' info in my *syslog* then edit rsyslog.conf and filter them rsyslog becomes all data which are logged but it can filter and journald can't # systemd-logind not in /var/log/messages :programname, isequal, systemd-logind -/var/log/secure :programname, isequal, systemd-logind ~ :msg, contains, Starting Session ~ :msg, contains, Started Session ~ :msg, contains, Stopping Session ~ :msg, contains, Stopped Session ~ 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] How to reduce systemd logging to syslog ?
Am 21.07.2014 15:18, schrieb Mantas Mikulėnas: On Mon, Jul 21, 2014 at 1:41 AM, sur...@emailengine.net wrote: 2014-07-20T00:15:01.978142-07:00 core systemd[1]: Starting Session 2 of user root. 2014-07-20T00:15:01.979526-07:00 core systemd[1]: Started Session 2 of user root. 2014-07-20T00:30:01.065850-07:00 core systemd[1]: Starting Session 3 of user root. 2014-07-20T00:30:01.067825-07:00 core systemd[1]: Started Session 3 of user root. 2014-07-20T00:45:01.155187-07:00 core systemd[1]: Starting Session 4 of user root. 2014-07-20T00:45:01.182571-07:00 core systemd[1]: Started Session 4 of user root. Looks like something – perhaps a cron daemon – opens a logind session every 15 minutes. But if I remember correctly, background jobs are not meant to do that at all? It might be that the log spam is caused by misconfigured /etc/pam.d/cron or something such... no it is caused by systemd and intentionally.. in F21 you get much more lines for cronjobs https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 Jan 15 04:07:01 testserver systemd[29118]: Starting Default. Jan 15 04:07:01 testserver systemd[29118]: Reached target Default. Jan 15 04:07:01 testserver systemd[29118]: Startup finished in 3ms. Jan 15 04:07:01 testserver systemd[1]: Started User Manager for 0. Jan 15 04:07:01 testserver systemd[1]: Stopping User Manager for 0... Jan 15 04:07:01 testserver systemd[29118]: Stopping Default. Jan 15 04:07:01 testserver systemd[29118]: Stopped target Default. Jan 15 04:07:01 testserver systemd[29118]: Starting Shutdown. Jan 15 04:07:01 testserver systemd[29118]: Reached target Shutdown. Jan 15 04:07:01 testserver systemd[29118]: Starting Exit the Session... Jan 15 04:07:01 testserver systemd[29118]: Received SIGRTMIN+24 from PID 29138 (kill). Jan 15 04:07:01 testserver systemd[1]: Stopped User Manager for 0. Jan 15 04:07:01 testserver systemd[1]: Stopping user-0.slice. Jan 15 04:07:01 testserver systemd[1]: Removed slice user-0.slice. Jan 15 04:08:01 testserver systemd[1]: Starting user-0.slice. Jan 15 04:08:01 testserver systemd[1]: Created slice user-0.slice. Jan 15 04:08:01 testserver systemd[1]: Starting User Manager for 0... Jan 15 04:08:01 testserver systemd[29149]: Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory Jan 15 04:08:01 testserver systemd[29149]: Starting Default. Jan 15 04:08:01 testserver systemd[29149]: Reached target Default. Jan 15 04:08:01 testserver systemd[29149]: Startup finished in 3ms. Jan 15 04:08:01 testserver systemd[1]: Started User Manager for 0. Jan 15 04:08:01 testserver systemd[1]: Stopping User Manager for 0... Jan 15 04:08:01 testserver systemd[29149]: Stopping Default. Jan 15 04:08:01 testserver systemd[29149]: Stopped target Default. Jan 15 04:08:01 testserver systemd[29149]: Starting Shutdown. Jan 15 04:08:01 testserver systemd[29149]: Reached target Shutdown. Jan 15 04:08:01 testserver systemd[29149]: Starting Exit the Session... Jan 15 04:08:01 testserver systemd[29149]: Received SIGRTMIN+24 from PID 29169 (kill). Jan 15 04:08:01 testserver systemd[1]: Stopped User Manager for 0. Jan 15 04:08:01 testserver systemd[1]: Stopping user-0.slice. Jan 15 04:08:01 testserver systemd[1]: Removed slice user-0.slice. Jan 15 04:09:01 testserver systemd[1]: Starting user-0.slice. Jan 15 04:09:01 testserver systemd[1]: Created slice user-0.slice. Jan 15 04:09:01 testserver systemd[1]: Starting User Manager for 0... Jan 15 04:09:01 testserver systemd[29181]: Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory Jan 15 04:09:01 testserver systemd[29181]: Starting Default. Jan 15 04:09:01 testserver systemd[29181]: Reached target Default. Jan 15 04:09:01 testserver systemd[29181]: Startup finished in 3ms. Jan 15 04:09:01 testserver systemd[1]: Started User Manager for 0. Jan 15 04:09:01 testserver systemd[1]: Stopping User Manager for 0... Jan 15 04:09:01 testserver systemd[29181]: Stopping Default. Jan 15 04:09:01 testserver systemd[29181]: Stopped target Default. Jan 15 04:09:01 testserver systemd[29181]: Starting Shutdown. Jan 15 04:09:01 testserver systemd[29181]: Reached target Shutdown. Jan 15 04:09:01 testserver systemd[29181]: Starting Exit the Session... Jan 15 04:09:01 testserver systemd[29181]: Received SIGRTMIN+24 from PID 29201 (kill). Jan 15 04:09:01 testserver systemd[1]: Stopped User Manager for 0. Jan 15 04:09:01 testserver systemd[1]: Stopping user-0.slice. Jan 15 04:09:01 testserver systemd[1]: Removed slice user-0.slice. Jan 15 04:10:01 testserver systemd[1]: Starting user-0.slice. Jan 15 04:10:01 testserver systemd[1]: Created slice user-0.slice. Jan 15 04:10:01 testserver systemd[1]: Starting User Manager for 0... Jan 15 04:10:01 testserver systemd[1]: Starting user-48.slice. Jan 15
Re: [systemd-devel] sysusers and login.defs checks
Am 22.07.2014 22:47, schrieb Colin Walters: On Mon, Jul 21, 2014, at 09:43 AM, Lennart Poettering wrote: I am pretty strongly against this. Making this administrator configurable apepars very wrong, this really should be a decision for the distribution vendor, and that's it. You list one concern below, are there others? We shouldn't design a system that comes to completely different results if you boot it up with and without /etc populated... If that's the only issue, surely we could just have it in the /usr/share/factory dir? As far as the rationale for having it administrator configurable - I think the idea is more that upgraded systems have a login.defs file with a min of 500, so humans in the midrange are still identified as such. This is called out on http://fedoraproject.org/wiki/Features/1000SystemAccounts Making the boundary configurable also allows some users to stay with the old boundary of 500, if they wish: Because /etc/login.defs is %config(noreplace), upgrades will retain the boundary value 500, and nothing should break. New installations in setups where the UIDs are centrally allocated (e.g. using LDAP) from 500 could be likewise configured to use the boundary value 500 by creating /etc/login.defs in a kickstart %pre script there are *a lot* of systems out there installed long before systemd was introduced and you can't safely dig around on dozens of machines and re-assign the owners of files there are data far away from /home don't fix things which ain't broken all that machines will *never* need dynamic user-id's abvoe 500 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] Changing configurations with networkd
Am 23.07.2014 12:47, schrieb Tom Gundersen: I think the lease should be remembered and reused in this case. In general, saving the lease to disk is probably not a good idea. We would need to store it on /var, and we may need to start the DHCP server before /var has been mounted. To the extent possible I would prefer to avoid that problem wheren't such cases the reason to invent /run? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: race conditions after SIGTERM
maybe that's a systemd thing i know Fedora 19 has not a recent systemd but the question remains if systemctl in case of Type=simple may act the same way while stop a service as for starting - send the SIGTERM and immediately return while the binary still writes data that could explain race conditions like below * stop mysqld instance 1 * stop mysqld instance 2 * the services still flush data but systemctl already returned * rsync both datadir * corruption Original-Nachricht Betreff: race conditions after SIGTERM Datum: Thu, 24 Jul 2014 12:42:51 +0200 Von: Reindl Harald h.rei...@thelounge.net An: Mailing-List mariadb maria-discuss@lists.launchpad.net how can that script lead to a race condition where files are not fully written to disk? that never happens if the systemd-unit for the replication instance has ExecStopPost=/usr/bin/sleep 1 and waits a while my only explaination is that mysqld returns after the SIGTERM from systemd before all data are completly written in some racy situations and so rsynced incompletly to the datadir of the other instance _ #!/bin/bash systemctl stop replication.service systemctl stop mysqld.service rsync $RSYNC_PARAMS /mysql_replication/ /mysql_data/ systemctl start replication.service systemctl start mysqld.service _ [Unit] Description=MariaDB Replication [Service] Type=simple PIDFile=/run/mysqld/mysqld_replication.pid ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my-replication.cnf --pid-file=/run/mysqld/mysqld_replication.pid --socket=/var/lib/mysql/mysql_replication.sock --open-files-limit=3 --basedir=/usr --user=mysql Environment=LANG=en_GB.UTF-8 Restart=always RestartSec=1 _ 140724 12:22:59 [Note] /usr/libexec/mysqld: Shutdown complete 140724 12:23:01 [Note] Plugin 'InnoDB' is disabled. Cannot find checkpoint record at LSN (1,0x35767) 140724 12:23:01 [ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on all Aria tables and delete all aria_log. files 140724 12:23:01 [ERROR] Plugin 'Aria' init function returned error. 140724 12:23:01 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed. 140724 12:23:01 [Note] Plugin 'FEDERATED' is disabled. 140724 12:23:01 [Note] Plugin 'FEEDBACK' is disabled. 140724 12:23:01 [ERROR] Aria engine is not enabled or did not start. The Aria engine must be enabled to continue as mysqld was configured with --with-aria-tmp-tables 140724 12:23:01 [ERROR] Aborting 140724 12:23:01 [Note] /usr/libexec/mysqld: Shutdown complete 140724 12:23:03 [Note] Plugin 'InnoDB' is disabled. Cannot find checkpoint record at LSN (1,0x35767) 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] race conditions after SIGTERM
and it happended again how can it be that if i have running mysqld-instances as Type=simple directly starting mysqld that it is not safe after systemctl stop returns to rsync the datadirs i had over a long time in any mysqld-unit ExecStopPost=/usr/bin/sleep 1 pretty sure because that happened in the past but that is a really dirty solution is 1 second enough, if not 2 or better 5 i have now a sleep 6 in the backup scripts - not beautiful after systemctl stop returns i expect that the MAINPID is *really* done, has finished it's cleanups and written data to disk and that systemd especially in case of a non-forking daemon knows trustable when it is finished Am 24.07.2014 13:24, schrieb Reindl Harald: maybe that's a systemd thing i know Fedora 19 has not a recent systemd but the question remains if systemctl in case of Type=simple may act the same way while stop a service as for starting - send the SIGTERM and immediately return while the binary still writes data that could explain race conditions like below * stop mysqld instance 1 * stop mysqld instance 2 * the services still flush data but systemctl already returned * rsync both datadir * corruption Original-Nachricht Betreff: race conditions after SIGTERM Datum: Thu, 24 Jul 2014 12:42:51 +0200 Von: Reindl Harald h.rei...@thelounge.net An: Mailing-List mariadb maria-discuss@lists.launchpad.net how can that script lead to a race condition where files are not fully written to disk? that never happens if the systemd-unit for the replication instance has ExecStopPost=/usr/bin/sleep 1 and waits a while my only explaination is that mysqld returns after the SIGTERM from systemd before all data are completly written in some racy situations and so rsynced incompletly to the datadir of the other instance _ #!/bin/bash systemctl stop replication.service systemctl stop mysqld.service rsync $RSYNC_PARAMS /mysql_replication/ /mysql_data/ systemctl start replication.service systemctl start mysqld.service _ [Unit] Description=MariaDB Replication [Service] Type=simple PIDFile=/run/mysqld/mysqld_replication.pid ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my-replication.cnf --pid-file=/run/mysqld/mysqld_replication.pid --socket=/var/lib/mysql/mysql_replication.sock --open-files-limit=3 --basedir=/usr --user=mysql Environment=LANG=en_GB.UTF-8 Restart=always RestartSec=1 _ 140724 12:22:59 [Note] /usr/libexec/mysqld: Shutdown complete 140724 12:23:01 [Note] Plugin 'InnoDB' is disabled. Cannot find checkpoint record at LSN (1,0x35767) 140724 12:23:01 [ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on all Aria tables and delete all aria_log. files 140724 12:23:01 [ERROR] Plugin 'Aria' init function returned error. 140724 12:23:01 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed. 140724 12:23:01 [Note] Plugin 'FEDERATED' is disabled. 140724 12:23:01 [Note] Plugin 'FEEDBACK' is disabled. 140724 12:23:01 [ERROR] Aria engine is not enabled or did not start. The Aria engine must be enabled to continue as mysqld was configured with --with-aria-tmp-tables 140724 12:23:01 [ERROR] Aborting 140724 12:23:01 [Note] /usr/libexec/mysqld: Shutdown complete 140724 12:23:03 [Note] Plugin 'InnoDB' is disabled. Cannot find checkpoint record at LSN (1,0x35767) 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] race conditions after SIGTERM
after that happend a few minutes ago systemd on F19: https://bugzilla.redhat.com/show_bug.cgi?id=1123557 since the sleep 1 was enough over months and now sleep 6 between systemctl stop and rsync is also not relieable my only conclusion is that systemd don't care about the still running MAINPID of type=simple and in case of a existing ExecStopPost the logic is correct looks like ExecStopPost is correctly executed after the MAINPID finished and without systemcl returns immediately i don't know if that affects F20/F21 too because i can't just upgrade production and that race happens once or twice a day and is hence not relieable to reproduce Am 25.07.2014 12:11, schrieb Reindl Harald: and it happended again how can it be that if i have running mysqld-instances as Type=simple directly starting mysqld that it is not safe after systemctl stop returns to rsync the datadirs i had over a long time in any mysqld-unit ExecStopPost=/usr/bin/sleep 1 pretty sure because that happened in the past but that is a really dirty solution is 1 second enough, if not 2 or better 5 i have now a sleep 6 in the backup scripts - not beautiful after systemctl stop returns i expect that the MAINPID is *really* done, has finished it's cleanups and written data to disk and that systemd especially in case of a non-forking daemon knows trustable when it is finished Am 24.07.2014 13:24, schrieb Reindl Harald: maybe that's a systemd thing i know Fedora 19 has not a recent systemd but the question remains if systemctl in case of Type=simple may act the same way while stop a service as for starting - send the SIGTERM and immediately return while the binary still writes data that could explain race conditions like below * stop mysqld instance 1 * stop mysqld instance 2 * the services still flush data but systemctl already returned * rsync both datadir * corruption Original-Nachricht Betreff: race conditions after SIGTERM Datum: Thu, 24 Jul 2014 12:42:51 +0200 Von: Reindl Harald h.rei...@thelounge.net An: Mailing-List mariadb maria-discuss@lists.launchpad.net how can that script lead to a race condition where files are not fully written to disk? that never happens if the systemd-unit for the replication instance has ExecStopPost=/usr/bin/sleep 1 and waits a while my only explaination is that mysqld returns after the SIGTERM from systemd before all data are completly written in some racy situations and so rsynced incompletly to the datadir of the other instance _ #!/bin/bash systemctl stop replication.service systemctl stop mysqld.service rsync $RSYNC_PARAMS /mysql_replication/ /mysql_data/ systemctl start replication.service systemctl start mysqld.service _ [Unit] Description=MariaDB Replication [Service] Type=simple PIDFile=/run/mysqld/mysqld_replication.pid ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my-replication.cnf --pid-file=/run/mysqld/mysqld_replication.pid --socket=/var/lib/mysql/mysql_replication.sock --open-files-limit=3 --basedir=/usr --user=mysql Environment=LANG=en_GB.UTF-8 Restart=always RestartSec=1 _ 140724 12:22:59 [Note] /usr/libexec/mysqld: Shutdown complete 140724 12:23:01 [Note] Plugin 'InnoDB' is disabled. Cannot find checkpoint record at LSN (1,0x35767) 140724 12:23:01 [ERROR] mysqld: Aria recovery failed. Please run aria_chk -r on all Aria tables and delete all aria_log. files 140724 12:23:01 [ERROR] Plugin 'Aria' init function returned error. 140724 12:23:01 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed. 140724 12:23:01 [Note] Plugin 'FEDERATED' is disabled. 140724 12:23:01 [Note] Plugin 'FEEDBACK' is disabled. 140724 12:23:01 [ERROR] Aria engine is not enabled or did not start. The Aria engine must be enabled to continue as mysqld was configured with --with-aria-tmp-tables 140724 12:23:01 [ERROR] Aborting 140724 12:23:01 [Note] /usr/libexec/mysqld: Shutdown complete 140724 12:23:03 [Note] Plugin 'InnoDB' is disabled. Cannot find checkpoint record at LSN (1,0x35767) 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] Support for pre-restart check
Am 30.07.2014 12:22, schrieb Ansgar Burchardt: while looking at how to convert sysvinit scripts to service files in Debian, I noticed that some scripts do an additional sanity check during the restart action. That is, they run an extra command to validate the configuration and only restart the service on success. Systemd doesn't seem to provide such an option so far. Would you think this is something one would like to see? If yes, what about the following idea: Add an ExecRestartPre option in the [Service] section. These commands are executed when a restart is requested, before the service is stopped. If they fail, the restart is aborted with an error as sysadmin i say: oh yes, that would be cool! the first canmdidate would be Apache httpd ExecRestartPre=/usr/sbin/apachectl -t that would cat cases where you hard restart httpd after library updates and some other guy made a typo in a config or is still woking on it apachectl graceful in such cases refuses the restart signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] documentation and required version
http://www.freedesktop.org/software/systemd/man/systemd.exec.html such error messages caused by list all sort of options without any information when they where introduced are really annoying - the docs should clearly say the minimum required systemd version and the more options are added the more important is that Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] Unknown lvalue 'RuntimeDirectory' in section 'Service' Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] Unknown lvalue 'RuntimeDirectoryMode' in section 'Service 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] Support for pre-restart check
Am 30.07.2014 13:42, schrieb Ansgar Burchardt: On 07/30/2014 13:26, Jóhann B. Guðmundsson wrote: On 07/30/2014 10:22 AM, Ansgar Burchardt wrote: Add an ExecRestartPre option in the [Service] section. These commands are executed when a restart is requested, before the service is stopped. If they fail, the restart is aborted with an error. This has been discussed before and check the archive for that discussion but the bottom line is that this is not needed we already have ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload= which cover those usecases I searched for such discussion, but did not find anything relevant. Do you have a link? And how would you use the existing Exec* options to cover this usecase? ExecStart* certainly doesn't help, ExecReload only works for reload and not for restart. ExecStop is to actually stop the service (and should not fail due to invalid configuration); ExecStopPost is too late they don't ExecStopPost is too late, the service is stopped ExecReload is a different game ExecStartPre don't help to prevent the stop hardly any of the existing options is able to *prevent stop* and ignore the systemctl restart - that would be the semnatic of a non existing ExecStopPre Pre != Post 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] documentation and required version
Am 30.07.2014 13:58, schrieb Tom Gundersen: On Wed, Jul 30, 2014 at 1:21 PM, Reindl Harald h.rei...@thelounge.net wrote: http://www.freedesktop.org/software/systemd/man/systemd.exec.html such error messages caused by list all sort of options without any information when they where introduced are really annoying - the docs should clearly say the minimum required systemd version and the more options are added the more important is that Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] Unknown lvalue 'RuntimeDirectory' in section 'Service' Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] Unknown lvalue 'RuntimeDirectoryMode' in section 'Service Won't this be solved by using the man pages shipped with the version of systemd you are using? no - for several reasons * it's more comfortable to use a website with working links like http://www.freedesktop.org/software/systemd/man/systemd.kill.html mentioned as example in ExecStop= * it's more comfortable to have STRG+F in a webbrowsers * i currently maintain machines with 204, 208 and 215 having *one* manual open which lists all available options and mention the minimum version of them gives a better picture 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] Support for pre-restart check
Am 30.07.2014 14:19, schrieb Jóhann B. Guðmundsson: On 07/30/2014 12:09 PM, Lennart Poettering wrote: On Wed, 30.07.14 12:22, Ansgar Burchardt (ans...@debian.org) wrote: while looking at how to convert sysvinit scripts to service files in Debian, I noticed that some scripts do an additional sanity check during the restart action. That is, they run an extra command to validate the configuration and only restart the service on success. Systemd doesn't seem to provide such an option so far. Would you think this is something one would like to see? If yes, what about the following idea: Add an ExecRestartPre option in the [Service] section. These commands are executed when a restart is requested, before the service is stopped. If they fail, the restart is aborted with an error. This has been a TODO item since a long time. The usecase seems valid. We discussed this either here on the mailinglist, in a bug report in bz.rh or in one of the hackfest and it's on that TODO list is there because in the beginning I thought this was required but after we discussed this the behaviour and after going through the more or less all of the legacy sysv initscripts in Fedora simply using ExecStartPre and ExecStop covered this but by all means introduce this if you no longer think that is the case *how* should that both help in calling apachectl -t *before* stop the service and in case of a error-repsonse keep it running? ExecStartPre can only prevent a not or no longer running service to start again, ExecStopPost comes after it is stopped and a ExecStopPre don't exist ExecStopPre would be better suited as the pre-restart check because it would achieve the goal and also prevent stop a service until it's configuration is fixed - that catchs cases where you stop something for whatever reason and expect it would be started at the next boot 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] Support for pre-restart check
Am 30.07.2014 14:35, schrieb Jóhann B. Guðmundsson: On 07/30/2014 12:02 PM, Reindl Harald wrote: they don't Perhaps not in your world which seems to differ from many don't jump on that personal level if you would have *read* really what you respond to and not stop at the first two words you would realize the difference without personal attacks - it's not a matter of worlds, it's a *technical fact* but in the world that the guy that went through and migrated around 800 legacy sysv initscript you want the exact same check run before the service is started and we already cover that with ExecStartPre= nobody takes ExecStartPre away from you by add ExecStopPre BTW: what do you gain by that checkj in ExecStartPre? ExecStart would fail anyways, so the service fails with or without the topic is about something like ExecStopPre, what you can achieve with it and not about which hero migrated how much sysv initscripts Ansgar Burchardt will need to post the initscript he's migrating so we can see if it actually provides an valid usecase to implement this I would be very surprised if it actually did... step beside your migration consideration and come back to a generic level by only consider migrations you could remove 80% of all options in systemd.exec that below could be httpd and that's useful for a lot of other services by just have the option to call a helper saying you don't stop me with the current environment because of XYZ you won't be able to start me again in case of httpd all what you need exists for other services it could be implemented if there is a call frankly that could be even useful outside the distribution world for sanity checks implemented by the local administrator Type=simple ExecStartPre=/usr/sbin/apachectl -t ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND ExecStopPre=/usr/sbin/apachectl -t ExecReload=/usr/sbin/httpd $OPTIONS -k graceful 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] Support for pre-restart check
Am 30.07.2014 15:04, schrieb Jóhann B. Guðmundsson: On 07/30/2014 12:34 PM, Reindl Harald wrote: *how* should that both help in calling apachectl -t *before* stop the service and in case of a error-repsonse keep it running? ExecStartPre= takes care of the startup check as in the usecase when the unit is not running and you initially configured the Apache daemon first: please don't ignore the last paragraphs! takes care about what? the service would fail with or without that Adding ExecStop= before actual ExecStop= line to stop the daemon takes care of preventing you from restarting you if you made configuration changes while the daemon/services was running should not continue with the stop process if the ExecStop command fails. but you don't need ExecStop for most services systemd sends SIGTERM and so ExecStopPre would also affect services without ExecStop lines which are most of mine why? because they don't need CAP_KILL! that's from production, no ExecStop used [Service] Type=simple EnvironmentFile=-/etc/sysconfig/httpd Environment=PATH=/usr/bin:/usr/sbin ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful Restart=always RestartSec=1 PrivateTmp=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib InaccessibleDirectories=/home InaccessibleDirectories=/media InaccessibleDirectories=/root InaccessibleDirectories=/proc InaccessibleDirectories=/sys InaccessibleDirectories=/run/console InaccessibleDirectories=/run/dbus InaccessibleDirectories=/run/lock InaccessibleDirectories=/run/mount InaccessibleDirectories=/run/systemd/generator InaccessibleDirectories=/run/systemd/system InaccessibleDirectories=/run/systemd/users InaccessibleDirectories=/run/udev InaccessibleDirectories=/run/user InaccessibleDirectories=/var/lib/dbus InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/lib/systemd InaccessibleDirectories=/var/lib/yum InaccessibleDirectories=/var/spool Anyway beside that point daemon,services that actual come with configuration file syntax checkers like apache does (maybe in what 20 or so range), are few and far between let alone those configuration syntax checker that actually exist out there fail properly if they do... step away from syntax checkers shipped with daemons, they are only one usecase (and maybe there would be some more in a few years with reliebale ways to use them with systemd) ExecStopPost could be any script written by the local administrator which says you don't stop that service in case service A and B are runnining which *hard fail* if you take them away the database and so i ordered start/shutdown of the machine correctly but without hard Requires= and their drawbacks in units files * drawbacks of Requires=: stop one service required by others stops them too, but start it don't start them at the same moment which is good because as example mysqld can run without dbmail-imapd but not the other way round so one could optimize the environment that restart/stop mysqld only is possible if dbamil-imapd is not running and systemctl restart dbmail-imapd.service mysqld.service does the correct order by After=/Before= in the services depending on mysqld 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] documentation and required version
Am 30.07.2014 17:31, schrieb Zbigniew Jędrzejewski-Szmek: Some of our man pages in section 3 partially have history, see e.g. [1]. I think having such information is very useful, but keeping it accurate is harder then it might seem at first. For example look at SocketUser/SocketGroup settings. They were added in systemd-214, but then were backported to 208-stable and 204-stable, and appeared in Fedora in a 204 update has Fedora 19 has been out for more than an a year [2] the distribution backports don't matter in that context the important information is feature sounds cool, what systemd version do i need at least with that i know how how my plans have do look like - grab if there is a backport is a different story, users need to know works on F20, F21 but not on F19 and RHEL7 options introduced with 208 as example are considered for my own rpm packages after the last machine is on F20 and if PrivateDevices would be available on F20 i would even give priority the F20 migration of our infrastructure It turns out that in this case man pages distributed with the system are a more accurate source of information then anything that could be included by upstream. So I'd be happy to merge patches which judiciously add history for manpages which describe API changes (i.e. section 3), but in general I don't think we have the man power to fully describe full history of all settings in systemd wrong way around - don't think that complicated somebody wrote that text below, see my fixed version at the end *now* it is a mess and likely nobody will be able to fix the past *but* for new options Introduced with systemd-XXX would be a no-brainer _ RuntimeDirectory=, RuntimeDirectoryMode= Takes a list of directory names. If set, one or more directories by the specified names will be created below /run (for system services) or below $XDG_RUNTIME_DIR (for user services) when the unit is started, and removed when the unit is stopped. The directories will have the access mode specified in RuntimeDirectoryMode=, and will be owned by the user and group specified in User= and Group=. Use this to manage one or more runtime directories of the unit and bind their lifetime to the daemon runtime. The specified directory names must be relative, and may not include a /, i.e. must refer to simple directories to create or remove. This is particularly useful for unprivileged daemons that cannot create runtime directories in /run due to lack of privileges, and to make sure the runtime directory is cleaned up automatically after use. For runtime directories that require more complex or different configuration or lifetime guarantees, please consider using tmpfiles.d(5). Introduced with systemd-214 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] Support for pre-restart check
Am 31.07.2014 um 07:03 schrieb Jóhann B. Guðmundsson: On 07/31/2014 12:16 AM, Colin Guthrie wrote: I think the use case is pretty clear tho'. Config (or general machine state) has transitioned from working to broken in the time since the service was started and while it's really not a nice situation to find yourself in (relying on a running service not crashng!), this at least helps avoid nasty consequences for the most part while you work to fix things. The use case administrator want, is fixing their own lazyness and incompetence not having to run the configuration syntax checker by hand after they made changes to the configuration for one of those handful of daemon/service that actually come with those. strange attitude calling safety lazyness and incompetence given that you can throw away a lot of things developed in the past 10 years to support the user in many different areas of IT 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] Support for pre-restart check
Am 31.07.2014 um 02:41 schrieb Michael Biebl: 2014-07-30 14:34 GMT+02:00 Reindl Harald h.rei...@thelounge.net: ExecStopPre would be better suited as the pre-restart check because it would achieve the goal and also prevent stop a service until it's configuration is fixed - that catchs cases where you stop something for whatever reason and expect it would be started at the next boot I don't think that would be a wise thing to do. If I want to reboot my system, it shouldn't fail to reboot because of a buggy apache configuration it could simply called and failing ignored in that case systemd knows that the system is at sthut down Apache should shutdown and simply fail to start on next reboot in that case yes Am 31.07.2014 um 02:16 schrieb Colin Guthrie: Reindl Harald wrote on 30/07/14 13:34: *how* should that both help in calling apachectl -t *before* stop the service and in case of a error-repsonse keep it running? Note, just for clarity, you don't really want to run such a config test when explicitly stopping a service i do want that in case it ends in a state where i can't start it afterwards systemctl stop X rsync data; systemctl start X and go to a coffee is not that uncommon that should always succeed IMO (unless you think that systemctl kill ... should be used in such circumstances?) i think so I really think an ExecRestartPre (or perhaps a more explicit ExecRestartCheck) would be a more sensible name (ExecStopPre implies it would run when explicitly stopping which, as noted above, I think is a bad plan). It wouldn't run when an ExecReload is given explicitly but if that operation falls back to restart, it would. falls back? how? when i say systemctl reload nothing has to trigger a hard restart and even if - in case of a broken config 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] documentation and required version
Am 04.08.2014 um 17:09 schrieb Lennart Poettering: On Wed, 30.07.14 13:21, Reindl Harald (h.rei...@thelounge.net) wrote: http://www.freedesktop.org/software/systemd/man/systemd.exec.html such error messages caused by list all sort of options without any information when they where introduced are really annoying - the docs should clearly say the minimum required systemd version and the more options are added the more important is that Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] Unknown lvalue 'RuntimeDirectory' in section 'Service' Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] Unknown lvalue 'RuntimeDirectoryMode' in section 'Service I am a bit conservative about doing this, since it would actually make the man pages much larger if we want this to be comprehensive. Also, I really don't want to litter the normal man pages with so much information about possibly pre-historical versions of systemd. It clutters the view, and makes people assume they would have to care for the old versions all times. I mean, currently many of the pages shipped with the manpages packages contain information about what feature is supported in 1.x kernels or in glibc 2, and stuff. And I really never ever want to be in the business of listing such cruft. What I'd be open to is if we keep this relatively isolated, strictly automatically generated and with a cutoff point where all versions that were released let's say 2y ago are subsumed under a single version. It shouldn't be too hard to write a script that automatically generates something like a minimal version of systemd.directives(7), that is enriched with data from the git history or so, and simply says Since 189 or so, for each of the configuration options. Happy to take a clean patch for something like that for Fedora 2 years would be fine to at least find the information if it is in old-stable, stable or Rawhide supported, for users of long supported distributions maybe not keep in mind systemd is now part of RHEL and Debian in the future i don't get why it is cruft to add at the end of the description while someone anyways needs to write it per hand (introduced with systemd-215) 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] race conditions after SIGTERM
Am 14.08.2014 um 14:22 schrieb Lennart Poettering: On Sun, 27.07.14 19:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sat, Jul 26, 2014 at 02:46:05PM +0200, Reindl Harald wrote: after that happend a few minutes ago systemd on F19: https://bugzilla.redhat.com/show_bug.cgi?id=1123557 since the sleep 1 was enough over months and now sleep 6 between systemctl stop and rsync is also not relieable my only conclusion is that systemd don't care about the still running MAINPID of type=simple and in case of a existing ExecStopPost the logic is correct Hi, PIDFile with Type=simple is not supported. Adding support would be tricky, because with Type=simple there's no obvious mechanism to notify systemd *when* to read the file. With Type=forking, when the first process exits, systemd knows it can read the file. It could be done with inotify maybe. A long-standing item on the TODO list is to add a new Type=pid-file or so that waits for a PID file to appear and uses that as indication when a daemon is up, or dies. I figure the example above would be a good case for this yes, but the problem is somewhere else look at the bugreport, it happened also witout the PIDFile line well, yesterday i upgraded production to Fedora 20 maybe that is now solved anyways i will report in both cases in the RH bugzilla * if it did not happen again for 3 weeks * if it happens again pretty sure a regression in the last F19 systemd update only in rare situations triggered or at least it got bader with that version since the /usr/bin/sleep 1 workaround did no longer help relieable 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] race conditions after SIGTERM
Am 14.08.2014 um 14:24 schrieb Lennart Poettering: On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: but that still don't explain why ExecStopPost=/usr/bin/true or whatever ExecStopPost solves that and if it is not supported why systemctl don't return after the one and only process exited Well, this is a misunderstanding how ExecStop= and friends are supposed to work. They are supposed to do what they did on sysvinit: synchronously terminate a service. And not asynchronously do that. We hence don't wait for anything else then, because what is left afterwards must be left-over processes that ExecStop= and friends couldn't clean up properly... no - the point was why was mysqld not finished with write down his ariadb-logs while systemctl returns and hence the corruption by start rsysnc the datadir in case of Type=simple and mysqld directly called in ExecStart without the mysqld_safe script there are not much processes to left over 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] race conditions after SIGTERM
Am 14.08.2014 um 19:51 schrieb Lennart Poettering: On Thu, 14.08.14 21:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: Which is what we do. Except when you specify ExecStop= which basically tells systemd that you want to do it instead. So there you go! Those daemons I have seen are terminated after receiving signal/command to do it. Those sysvinit scripts that synchronously terminated services did it by implementing wait for daemon process to exit. What is worse, the only way to do it is busy looping as they cannot normally receive notification about process exit. Well, if they don't have such a protocol, then they can use systemd's default logic for this, and just tweak the parameters. KillMode=, KillSignal=, TimeoutStopSec= are all ways how you can control how exactly systemd should terminate your service. Compare this with send daemon command - signal or whatever - and wait until it exits. This needs to be implemented just once in PID 1 - and PID 1 already does exactly this most of the time anyway. Why is this the wrong thing to do? You never explained this when you rejected my patch. Hmm, this is what we do. By specifiying ExecStop= you turn that off however can plug in your own logic. If you don't have any better logic, then simply don't plug anything in, that's what we recommend anyway. Again: systemd does what you want it to do by default, anyway. By specifiying ExecStop= you however turn this off, and have to do it on your own! Uhm - i did not have *any* ExecStop / EexecStopPost until it came to compromised mysqld datafiles - other than the Fedora packages i just used Type=simple ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/run/mysqld/mysqld.pid after problems i added ExecStartPost=/usr/bin/sleep 1 which avoided the problems most of the time but implicates a useless second at shutdown *currently* i added ExecStop=/usr/bin/kill -15 $MAINPID and upgraded to Fedora 20 in the hope systemd-208 does that better than systemd-204 on Fedora 19 __ *normally* i would expect ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf --pid-file=/run/mysqld/mysqld.pid Restart=always RestartSec=1 TimeoutSec=300 as the only start / stop configuration and be sure after systemctl stop mysqld returns the daemon process is really away and had written what he needs and starting rsync the datadir is safe that is not the case, hence the thread and bugreport for systemd on F19 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] Link down for systemd articles
Am 18.08.2014 um 15:19 schrieb Lennart Poettering: On Mon, 18.08.14 12:45, Saket Sinha (saket.sinh...@gmail.com) wrote: I have been working on systemd recently and was referring to articles by Lennart Poettering for the same. However, I am not able to access the articles hosted at the below link - http://0pointer.de/blog/projects/ Is the server down or something ? Somebody found it funny to DoS my server with HTTP or so. I turned HTTP off temporarily. I have now started it again ctstate NEW recent: UPDATE seconds: 2 hit_count: 150 name: udpflood side: source mask: 255.255.255.255 ctstate NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source mask: 255.255.255.255 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/32 75 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/24 150 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/16 175 multiport dports 25,80,443,465,587 tcp flags:0x17/0x02 #conn src/8 200 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] Make journalctl start at the end of the journal by default
Am 18.08.2014 um 15:27 schrieb Lennart Poettering: And also I would like to see the full logs always by default. Usually after lots of searching you find the offending log entry for the error, only to find out you forgot to pass the right command line options to journalctl and the important bit is cut off. cut off? You can just scroll to the right in most pagers, such as less? that don't change the fact --full should be the default instead force anybody with a smaller screen to create aliases if he want to read things just by use the scrollbar modern terminal applications like konsole offer 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] Setting Up SSH Tunnels
Am 05.07.2013 19:16, schrieb cac...@quantum-sci.com: For some years I've set up reverse SSH tunnels with a script, but when the tunnels go down they do not recover. I'd like to start and stop the tunnels using systemd. A typical command looks like this: /usr/bin/ssh -f -l sleeper -i /home/sleeper/.ssh/id_ecdsa -2 -4 -c aes256-ctr,aes128-ctr -L 3128:localhost:3128 droog sleep 365d I tried invoking my script with a .service file, but it doesn't keep the tunnels alive. (sometimes they die with broken pipe) And it doesn't re-establish the tunnels on wake from sleep. This is my .service file: # sshdroog.service [Unit] Description= reverse SSH tunnels Before=rc.local.service After=network.target sockets.target syslog.target [Service] # Do a single job and then exit (Can have multiple ExecStarts): Type=oneshot # For oneshot, so that systemd still considers the service as active after the process has exited: RemainAfterExit=yes ExecStart=/usr/local/bin/sshcygnus ExecStop=/bin/kill -15 $MAINPID Restart=always RestartSec=2 TimeoutSec=60 # Errors in /var/log/messages systemd.log_level=debug #Type=notify #StandardError=syslog #NotifyAccess=main [Install] WantedBy=multi-user.target oneshot is plain wrong if you have a long living prcoess below a working unit to have a remote-server's ssh on localhost:10024 RestartSec=60 because so it survives reboots of the forwarded machine with auto reconnect [Unit] Description=SSH-Forwarding After=network.service openvpn.service [Service] Type=simple ExecStart=/usr/bin/ssh -i /home/gateway/.ssh/id_rsa gateway@target-host -N -C -L127.0.0.1:10024:127.0.0.1:22 Restart=always RestartSec=60 TimeoutSec=30 [Install] WantedBy=multi-user.target 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] Setting Up SSH Tunnels
Am 05.07.2013 21:20, schrieb cac...@quantum-sci.com: Reindl Harald: oneshot is plain wrong if you have a long living prcoess below a working unit to have a remote-server's ssh on localhost:10024 RestartSec=60 because so it survives reboots of the forwarded machine with auto reconnect [Unit] Description=SSH-Forwarding After=network.service openvpn.service [Service] Type=simple ExecStart=/usr/bin/ssh -i /home/gateway/.ssh/id_rsa gateway@target-host -N -C -L127.0.0.1:10024:127.0.0.1:22 Restart=always RestartSec=60 TimeoutSec=30 [Install] WantedBy=multi-user.target Thank you. But this is good for only one port, and I have over 20. i have 6 This is the reason I used oneshot, as you can have multiple ExecStarts. Of course it doesn't work. i know, been there, done that But does this mean I have to have over 20 .services for my reverse tunnels? They could all start in parallel, but is there no better way? this is a *perfect* way and the only one Restart=always can work relieable no matter how many of them, build one, test it carefully and copy it as often as need with the minimal change of port/host, that's hardly more work than a unrelieable wrapper script with the small script below i see the status of all forwarding-services including all ssh processes with their params and the last restart-time what more does someone need to manage this out-of-the-box? cat /usr/local/bin/forwardings.sh #!/usr/bin/bash if [ $1 == ]; then ACTION=status else ACTION=$1 fi /usr/bin/systemctl $ACTION forward-host1.service forward-host2.service... Would they wake from sleep? Would they auto-restart if a broken pipe? anything which let die the ssh process results in restart 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] My last post went as unprocessed
Am 11.07.2013 22:36, schrieb David Lambert: Thanks for your quick reply. I also notice a - preceding the target for ExecStart target. How does this work and where is it documented. Again very difficult to search :-[ the command is allowed to fail without failing the service it's common for EnvironemntFiles which are used if present and ignored if not in case of sshdgenkeys.service the way to go because the kyes must be generated at the first start but *must not* be overwritten at any later time [Unit] Description=OpenSSH Per-Connection Daemon After=sshdgenkeys.service [Service] ExecStart=-/usr/sbin/sshd -i ExecReload=/bin/kill -HUP $MAINPID StandardInput=socket StandardError=syslog 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] fstab Mounts Not Getting Waken Up
Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot 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] fstab Mounts Not Getting Waken Up
Am 12.07.2013 17:54, schrieb Dave Reisner: On Fri, Jul 12, 2013 at 05:46:37PM +0200, Reindl Harald wrote: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot I direct you to mount(8): The programs mount and umount support filesystem subtypes. The subtype is defined by '.subtype' suffix. For example 'fuse.sshfs'. It's recommended to use subtype notation rather than add any prefix to the mount source (for example 'sshfs#example.com' is deprecated) there is a difference between is deprecated while there is no single message in /var/log/messages where it would belong to in this case or claim is wrong as you did! 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] fstab Mounts Not Getting Waken Up
Am 12.07.2013 17:58, schrieb cac...@quantum-sci.com: Reindl Harald: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot Reindl, thank goodness you're listening. Have you by chance, tried this with auto, to see whether it automounts on wake from suspend? sorry, i stopped in 2011 to use notebooks forever and all and switched to workstations with RAID10 which are 365 days a year on or at least the whole workday i only stepped in to correct the Your use of sshfs# as a FUSE type is wrong which at least should have been is deprecated at least as long the mount command comes with this: [root@srv-rhsoft:~]$ mount.fuse --help usage: mount.fuse type#[source] destination [-t type] [-o opt[,opts...]] signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] question about SecureBits / NoNewPrivileges
Hi i try to secure the Apache-Webserver (mpm-prefork) as much as possible am i right that with the following settings in the systemd-unit after the child-process is forked with the apache user and the capabilities are reduced as below even a potential root exploit would have no success? SecureBits=noroot fails i guess because it even disallows the parent-process to run as root after start SecureBits=noroot-locked NoNewPrivileges=yes CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRIDE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK _ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/httpd.service [Unit] Description=Apache Webserver After=network.service [Service] Type=simple EnvironmentFile=-/etc/sysconfig/httpd ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop KillSignal=SIGCONT TimeoutStopSec=2 Restart=always RestartSec=1 UMask=006 PrivateTmp=yes SecureBits=noroot-locked NoNewPrivileges=yes CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRIDE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK InaccessibleDirectories=/boot InaccessibleDirectories=/home InaccessibleDirectories=/root InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/spool [Install] WantedBy=multi-user.target 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] question about SecureBits / NoNewPrivileges
Am 25.07.2013 20:00, schrieb Lennart Poettering: On Sat, 20.07.13 04:06, Reindl Harald (h.rei...@thelounge.net) wrote: Hi i try to secure the Apache-Webserver (mpm-prefork) as much as possible am i right that with the following settings in the systemd-unit after the child-process is forked with the apache user and the capabilities are reduced as below even a potential root exploit would have no success? SecureBits=noroot fails i guess because it even disallows the parent-process to run as root after start IIRC combining NoNewPrivileges with CAP_SETUID doesn't really make much sense as the latter is one way how to gain new privs, but the former doesn't allow this well, but httpd needs CAP_SETUID to *lower* the privileges after start for the child-processes and needs root at startup as well as for the master-prcoess which opens logfiles and othe filehandles not allowed to do for the user apache that is why my idea of the setting is OK, once you dropped your privileges nothing will allow to get back root permissions 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] [PATCH] man: Add a note about what environment variables are available by default.
Am 26.07.2013 12:03, schrieb Kay Sievers: man/systemd.exec.xml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index c0e1d86..b78f255 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -77,6 +77,13 @@ configuration options are configured in the [Service], [Socket], [Mount], or [Swap] sections, depending on the unit type./para + +paraAll processes are executed in a clean environment in +which only the TERM, PATH, USER, and HOME variables are set +by default. They are just preserved, passed-along, not exported or set by default, isn't it? Seems for the system services, only PATH= and the locale are usually set: $ sudo cat /proc/$(pidof systemd-logind)/environ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binLANG=en_US.UTF-8LC_TIME=de_DE.UTF-8LC_PAPER=de_DE.UTF-8LC_MEASUREMENT=de_DE.UTF-8 on Fedora 18 (systemd-201-2.fc18.7.x86_64) and Fedora 17 (systemd-44-24.fc17.x86_64) i see more like BOOT_IMAGE which also appears all in phpinfo() cat /proc/$(pidof systemd-logind)/environ BOOT_IMAGE=/vmlinuz-3.9.11-200.fc18.x86_64divider=10biosdevname=0LANG=de_DE.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin cat /proc/$(pidof systemd-logind)/environ SYSFONT=latarcyrheb-sun16PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/binbiosdevname=0LANG=de_DE.UTF-8divider=20KEYTABLE=de-latin1-nodeadkeysBOOT_IMAGE=/vmlinuz-3.9.10-100.fc17.x86_64 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] /etc/systemd/system/darkice.service
Am 28.07.2013 11:06, schrieb Kai Hendry: On 26 July 2013 04:17, Lennart Poettering lenn...@poettering.net wrote: We generally generate warnings about invalid lines and proceed. Aftre we parsed everything we then do a couple of checks whether a unit still makes sense with the stuff that was correctly parsed, and only if the unit does't pass that check we will fail it. I managed to see a foobar.service lacks ExecStart setting. Refusing. if I put ExecStart under [Unit] but if I do something like put Description under [Service] I don't get a warning. Maybe it's just me that finds it hard to know which stanzas belong under which heading man systemd.unit man systemd.service look at a existing unit /usr/lib/systemd/system/avahi-daemon.service as example _ [Unit] Description=Avahi mDNS/DNS-SD Stack Requires=avahi-daemon.socket [Service] Type=dbus BusName=org.freedesktop.Avahi ExecStart=/usr/sbin/avahi-daemon -s ExecReload=/usr/sbin/avahi-daemon -r NotifyAccess=main [Install] WantedBy=multi-user.target Also=avahi-daemon.socket Alias=dbus-org.freedesktop.Avahi.service 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] guidance on how to get systemd to function
Am 02.08.2013 12:01, schrieb lux-integ: thanks for your reply Would you care to elaborate what PID1 is please? https://www.google.com/search?q=PID1#sclient=psy-abq=PID1+linux http://0pointer.de/blog/projects/systemd.html signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system
Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system please drop this deprectaion, it is disturbing and useless if you want a forced fsck for *whatever* reason you do *not* want to edit the grub-config and need to remove it after pass to prevent on the next boot a unintented fsck nor do you want to struggle with the boot-menu on remote-machines this warning is pointless and useless 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] What is the best way to run a shell script through 'ExecStart'
Am 30.09.2013 15:31, schrieb Tom Gundersen:
On Mon, Sep 30, 2013 at 3:25 PM, Muhammad Shakeel
muhammad_shak...@mentor.com wrote:
I have been trying to convert a LSB initscript of a package into
corresponding systemd service fyile. Most init scripts are simple and
translating them into systemd unit files is non-trivial. In this case it is
a relatively long script involving some loops.
1) Should I write a script file separately and then call it through
'ExecStart'?
or
2) It would be good (and do-able) idea to fit whole script inside
ExecStart=/bin/sh -c script? (If yes, I would prefer it as it will free
me from hassle of maintaining two files)
If you need something non-trivial (such as loops or a script over more
than a couple of lines), then I suggest keeping it in a separate file.
Systemd service files intentionally do not support loops (or other
control structures)
i tend to use PHP for most things because re-use of internal libraries
and a simple endless loop with type=simple does it's job
#!/usr/bin/php
while(1 == 1)
{
}
___
cat /etc/systemd/system/monitor-dbmail-imapd.service
[Unit]
Description=monitor dbmail-imapd
After=dbmail-imapd.service
[Service]
Type=simple
ExecStart=/usr/local/bin/check-dbmail-service.php 143 dbmail-imapd
Restart=always
RestartSec=1
TimeoutSec=1
Nice=19
IOSchedulingClass=3
User=dbmail
Group=dbmail
PrivateTmp=true
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_KILL
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/proc
ReadOnlyDirectories=/sys
InaccessibleDirectories=/boot
InaccessibleDirectories=/home
InaccessibleDirectories=/var/lib/rpm
InaccessibleDirectories=/var/lib/yum
InaccessibleDirectories=/var/spool
[Install]
WantedBy=multi-user.target
___
cat /usr/local/bin/check-dbmail-service.php
#!/usr/bin/php
?php
/** make sure we are running as shell-script */
if(PHP_SAPI != 'cli')
{
exit('FORBIDDEN');
}
/** verify that port and binary-name are given */
if(empty($_SERVER['argv'][1]) || empty($_SERVER['argv'][2]))
{
exit('USAGE: check-dbmail-service port process-name' . \n);
}
/** service loop */
while(1 == 1)
{
if(!check_service())
{
sleep(5);
if(!check_service())
{
passthru('/usr/bin/killall -s SIGTERM ' .
escapeshellarg($_SERVER['argv'][2]));
usleep(75);
passthru('/usr/bin/killall -s SIGKILL ' .
escapeshellarg($_SERVER['argv'][2]));
}
}
sleep(30);
}
/**
* check if service is available and responds
*
* @access public
* @return boolean
*/
function check_service()
{
$errno = 0;
$errstr = '';
$fp = @fsockopen('tcp://127.0.0.1', $_SERVER['argv'][1], $errno, $errstr, 5);
if($fp)
{
$response = @fgets($fp, 128);
@fclose($fp);
if(!empty($response))
{
return true;
}
else
{
return false;
}
}
else
{
return false;
}
}
?
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] moving from SysV to systemd - issue with / being ro
Am 16.10.2013 19:22, schrieb Warpme: On 10/16/13 7:02 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 16, 2013 at 06:18:12PM +0200, Warpme wrote: Hi, I want to switch init system from SysV to systemd-196. Sys is PXE booted disk-less appliance with rootfs based on overlayfs. Currently I can PXEboot, successfully switch root from initrd to overlayfs based root, systemd starts and executes many of it's units. Unfortunately user units are failing due / is read-only. When I issue mount -o remount,rw / - root becomes rw - so it looks like systemd for some reason isn't remounting root to rw. Interesting is that exactly the same initrd-overlayfs script (see below) works OK for SysV - so I think issue isn't in my pivot_root procedure but rather systemd receives / in rw but leaves in ro (as mount -o remount,rw / allows to write to /). Script switching initrd to overlayfs root looks following: /bin/mount -n -t tmpfs none /rw /bin/mkdir -p /rw/rootfs /bin/mount -n -t overlayfs -o lowerdir=/rootfs-ro,upperdir=/rw/rootfs none /rootfs cd /rootfs /bin/mkdir -p initrd proc sys /sbin/pivot_root . initrd exec /usr/sbin/chroot . /usr/lib/systemd/systemd Where issue might be? What's in /etc/fstab? Zbyszek Zbyszku, Here is my fstab: none / auto remount,rw 0 0 why none and remount? typically the line looks like this UUID=b834776d-69d1-49c6-97c1-d6d758a438f0 / ext4 defaults i doubt that anything smells what none means 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] moving from SysV to systemd - issue with / being ro
Am 17.10.2013 14:59, schrieb Warpme: On 10/16/13 9:46 PM, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 16, 2013 at 09:19:43PM +0200, Warpme wrote: Maybe we should disable [re]mounting / by systemd at all? All systemd does, is call 'mount -o remount /'. I have no idea how you end up with a read-only filesystem. As a work-around, you can add /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf with [Service] ExecStartPost=mount -o remount,rw / and/or run systemd in debug mode (add systemd.log_level=debug on the kernel command line), to see what is going on. Zbyszek Adding /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf not helps. When I enable debugging by adding systemd.log_level=debug I'm receiving tons of messages about started/failed journal. Probably due / being in ro mode. Is it possible that ro issue is because I'm building systemd with minimal enabled features ? you should not disable configure options like a butcher and at least not from start normally you build software with default options and try what you can remove and change before things start to break horrible, not the other way --disable-pam --disable-acl --disable-xattr is for sure not smart adn many of the others are questionable if you are not on a embedded device My configure line is following: --disable-nls \ --disable-gtk-doc \ --disable-gtk-doc-html \ --disable-gtk-doc-pdf \ --enable-introspection=no \ --disable-ima \ --disable-selinux \ --disable-xz \ --disable-tcpwrap \ --disable-pam \ --disable-acl \ --disable-xattr \ --disable-gcrypt \ --disable-audit \ --disable-libcryptsetup \ --disable-qrencode \ --disable-microhttpd \ --disable-binfmt \ --disable-vconsole \ --disable-readahead \ --disable-quotacheck \ --disable-randomseed \ --disable-logind \ --disable-hostnamed \ --disable-timedated \ --disable-localed \ --disable-coredump \ --disable-gudev \ --disable-keymap \ --disable-manpages \ --enable-split-usr \ --without-python \ LIBS=$(DESTDIR)$(libdir)/libcap.so 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] Newbie question - Requires doesn't work properly
Am 22.11.2013 03:04, schrieb salil GK: Thanks a lot David On 22 November 2013 06:44, David Timothy Strauss da...@davidstrauss.net mailto:da...@davidstrauss.net wrote: On Thu, Nov 21, 2013 at 4:57 PM, salil GK gksa...@gmail.com mailto:gksa...@gmail.com wrote: What happens is - my process may be busy with some other activity during which time it will fail to send periodic message to systemd. After a while it will come out of it's loop and ready to serve. But during this time system would have already marked the process as failed. Then you need to either use another thread, refactor to make a tighter event loop, or increase the watchdog time. Drifting in and out of tolerance with watchdog is not a safe strategy. the problem i see with use another thread is that this thread can happily work and send it's keep alive, but that does not mean at the end that the service itself is working OK and responsible because both are running isolated in case of network services it would be pretty cool if systemd watchdog could be configured to connect to the service avery n seconds and if there is no response restart it because this would monitor the real service without need external tools 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] Newbie question - Requires doesn't work properly
Am 22.11.2013 12:49, schrieb David Timothy Strauss: It is the responsibility of whatever sends the watchdog to ensure everything's healthy, however necessary. It would be silly to spawn a thread and have it blindly report health to watchdog. The point is for that thread to do proper checks but ensure reports go in at the right intervals. i know that but the *how* is the question you can internally check what not but that does not mean at the end of the day the service responds correctly to a client connection over the network until you do not go through the same stack meaning doing a network connection i spent hundrets of hours in upstream-debugging of dbmail to find spinlocks and what not else only happening in rare situations, one of them took 16 hours stress tests until it happend with debug-log enabled while on the real server it took a few minutes to get triggered by a random client action that's the difference between theory and real workload your internal checks are mostly theory because in case of a bug you have undefined behavior and what you want to achieve with the watchdog is catch this undefined behavior and restart the service - in doubt this will not work in the rare cases the watchdog should restart until you went the complete code-path of a client, in case of a IMAP server you can enter the spin-loop everywhere from accept the connection to folder listing or receive a message and it may depend on a buffer overflow while high concurrency and different threads are touching each other in a unexpected way been there, died nearly in debug it and catch data for upstream On Nov 22, 2013 7:50 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 22.11.2013 03:04, schrieb salil GK: Thanks a lot David On 22 November 2013 06:44, David Timothy Strauss da...@davidstrauss.net mailto:da...@davidstrauss.net mailto:da...@davidstrauss.net mailto:da...@davidstrauss.net wrote: On Thu, Nov 21, 2013 at 4:57 PM, salil GK gksa...@gmail.com mailto:gksa...@gmail.com mailto:gksa...@gmail.com mailto:gksa...@gmail.com wrote: What happens is - my process may be busy with some other activity during which time it will fail to send periodic message to systemd. After a while it will come out of it's loop and ready to serve. But during this time system would have already marked the process as failed. Then you need to either use another thread, refactor to make a tighter event loop, or increase the watchdog time. Drifting in and out of tolerance with watchdog is not a safe strategy. the problem i see with use another thread is that this thread can happily work and send it's keep alive, but that does not mean at the end that the service itself is working OK and responsible because both are running isolated in case of network services it would be pretty cool if systemd watchdog could be configured to connect to the service avery n seconds and if there is no response restart it because this would monitor the real service without need external tools 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] Presentation was a success
Am 06.12.2013 12:17, schrieb Cecil Westerhof: On 12/06/2013 11:31 AM, poma wrote: In 7th slide - Improvements - Only necessary kernel modules How does it actually refers to systemd? You do not need to have modules loaded that are not used much. They can be loaded when a program that needs them is run and unloaded when the program terminates. This is done with: /etc/modules-load.d/PROG.conf I'll try to make a video tonight to demonstrate this /etc/modules-load.d/ *adds* modules otherwise not loaded by the kernel and they are loaded at boot 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] Presentation was a success
Am 06.12.2013 12:38, schrieb Cecil Westerhof: On 12/06/2013 12:30 PM, Reindl Harald wrote: In 7th slide - Improvements - Only necessary kernel modules How does it actually refers to systemd? You do not need to have modules loaded that are not used much. They can be loaded when a program that needs them is run and unloaded when the program terminates. This is done with: /etc/modules-load.d/PROG.conf I'll try to make a video tonight to demonstrate this /etc/modules-load.d/ *adds* modules otherwise not loaded by the kernel and they are loaded at boot Strange I thought that I used this to have the loop module loaded when starting truecrypt and unloaded when stopping truecrypt. I have to check this out no, it is to have the module loaded when truecrypt is installed and stop try to load it at boot after it is uninstalled, there is not much to checkout because the syntax of the file even in theory has no connection to a running process and so it can't work this way additionally it would be wrong because unload kernel modules is not always a good idea - better said: it is rarely a good idea if not done by hand for a reason 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] Presentation was a success
Am 06.12.2013 15:36, schrieb Cecil Westerhof: On 12/06/2013 12:43 PM, Reindl Harald wrote: Am 06.12.2013 12:38, schrieb Cecil Westerhof: On 12/06/2013 12:30 PM, Reindl Harald wrote: In 7th slide - Improvements - Only necessary kernel modules How does it actually refers to systemd? You do not need to have modules loaded that are not used much. They can be loaded when a program that needs them is run and unloaded when the program terminates. This is done with: /etc/modules-load.d/PROG.conf I'll try to make a video tonight to demonstrate this /etc/modules-load.d/ *adds* modules otherwise not loaded by the kernel and they are loaded at boot Strange I thought that I used this to have the loop module loaded when starting truecrypt and unloaded when stopping truecrypt. I have to check this out no, it is to have the module loaded when truecrypt is installed and stop try to load it at boot after it is uninstalled, there is not much to checkout because the syntax of the file even in theory has no connection to a running process and so it can't work this way additionally it would be wrong because unload kernel modules is not always a good idea - better said: it is rarely a good idea if not done by hand for a reason I made a screencast some time ago. The part from 09:10 to 12:10 shows this happening. (loading and unloading when truecrypt is started and quit) does not change the fact that /etc/modules-load.d/ loads at boot and is not involved in unload modules 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] Logging in an enterprise environment
Am 11.12.2013 14:43, schrieb Cecil Westerhof: On 12/11/2013 02:25 PM, Cecil Westerhof wrote: You can to centralized logging with the journal too, by simply making the journal files you want to look at accessible on the same machine. This could be done via NFS sharing, or by copying them to a central host via rsync or scp or even ftp, whatever you prefer. journalctl -m will then be able to coalesce them on display. NFS is not acceptable I am told, but I'll inquire about the other possibilities. By the way: is just copying possible? What if an event is logged at the moment the copy is done? I just had a little check. Copying is not acceptable. Logging on the log-server should be real-time so just install rsyslog and you have the same as before rsyslog is running here on any machine and journald with Storage=none 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] No security on systemd-journal-gatewayd
Am 11.12.2013 22:41, schrieb Cecil Westerhof: I tried out systemd-journal-gatewayd. But it looks like that everyone that can contact, can get log info. Is that true, or am I overlooking something? as far as i remeber from older posts about it the intention is that a) it is not on by default b) if you turn it on you need to open the port in the firewall too c) if you open the port you do this only for trusted sources signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] dmesg: Vacuuming done, freed xxx bytes
is it really needed to pass this messages to dmesg instead syslog or supress them? it is disturbing in cases you distribute dmesg over a infrastructure with more than 20 machines [941542.003467] systemd-journald[22511]: Vacuuming done, freed 2879488 bytes [944310.095412] systemd-journald[22511]: Vacuuming done, freed 2875392 bytes [947130.481168] systemd-journald[22511]: Vacuuming done, freed 2883584 bytes [949921.017800] systemd-journald[22511]: Vacuuming done, freed 2875392 bytes [952696.026187] systemd-journald[22511]: Vacuuming done, freed 2805760 bytes [955908.163206] systemd-journald[22511]: Vacuuming done, freed 2826240 bytes 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] fstrim cron job
Am 21.12.2013 14:44, schrieb Kay Sievers: Trimming should be the job of the filesystem, not for a nasty cron job. We do not want to support legacy filesystems with upstream shipped systemd units. doing it permanently on the fs-layer degrades all time performance doing it in a cron job regulary does not affect performance that way Readahead is pointless and wrong enough already to ship and enable in systemd; using slows down bootup on all of my machines yes and no the question is not only hwo long the boot process itself takes how long does it take until you KDE/GNOME session is fully loaded there are always a few seconds between boot and enter username / pwd in this time window readahead already loads things from disk which are need due login - the summary of both is the interesting number 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] fstrim cron job
Am 21.12.2013 15:23, schrieb Kay Sievers: On Sat, Dec 21, 2013 at 3:11 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 21.12.2013 14:44, schrieb Kay Sievers: Trimming should be the job of the filesystem, not for a nasty cron job. We do not want to support legacy filesystems with upstream shipped systemd units. doing it permanently on the fs-layer degrades all time performance doing it in a cron job regulary does not affect performance that way No. Modern filesystems are like kernel services not silent and dumb dong nothing in the background. They can do whatever they need to do in whatever manner, and they can do it right. that's no the point the point is that mountig with trim means every time you delete something the physical disks get notified, doing it once per day avoids this overhead Readahead is pointless and wrong enough already to ship and enable in systemd; using slows down bootup on all of my machines yes and no the question is not only hwo long the boot process itself takes how long does it take until you KDE/GNOME session is fully loaded there are always a few seconds between boot and enter username / pwd in this time window readahead already loads things from disk which are need due login - the summary of both is the interesting number I have auto-login and using read-ahead was just slower yes because auto-login - for the sake of security not to recommend in that case you gain nothing because there is no time window between boot and login Maybe the new block multi-queue stuff changes the picture; but in general I'm convinced that read-ahead is a tool from the past on current modern systems/SSDs, it should no longer be enabled by default define modern systems as long as SD cards are dying silent without any error and claiming data are written while delete, format with several filesystems and overwrite with /dev/zero as well as /dev/urandom leads to after remove the card and insert it again the old data is still there like all the overwrites and formats never happened i stay on not so modern RAID10 spindles with 4 to 12 disks which are not really slower for most usecases, more reliable and much larger flash devices typically are dying from one moment to the next while a classical harddisk starts to throw errors long before 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] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.
Am 30.12.2013 18:53, schrieb Zbigniew Jędrzejewski-Szmek: I found another one: - https://bugs.freedesktop.org/show_bug.cgi?id=66912 Autocompletion does not propose template units which have some instances enabled may I notice this one in context of autocompletion too https://bugzilla.redhat.com/show_bug.cgi?id=1024379 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] network-online.target and manual mounts
Am 01.01.2014 22:13, schrieb Andrey Borzenkov: В Ср, 01/01/2014 в 15:00 -0500, Dave Reisner пишет: On Wed, Jan 01, 2014 at 11:43:15PM +0400, Andrey Borzenkov wrote: systemd.special(7) suggests that network-online.target should be pulled in by consumer. Unfortunately, that means that when booting without active consumer (let's say no NFS mounts in fstab) network-online.target is not started at all. If NFS is mounted manually later, no synchronization point exists on shutdown, so network may be stopped before NFS is unmounted. This leads to prolonged timeout. Is there any mechanism to start it when NFS (or other network) mount appears? The very existence of network mount could be considered as indication that network *is* online? I think tihs is a post-v208 change, but if you manually mount a network share manually after booting, network-online.target is pulled in as Wants= and After=. This should make for correct ordering on shutdown. # mount.cifs //10.0.2.1/pkgs pkg -o defaults,guest,rw # systemctl show -p After -p Wants $PWD/pkg Wants=network-online.target system.slice After=systemd-journald.socket remote-fs-pre.target network.target network-online.target system.slice -.mount Yes, units automatically created from existing mounts do get Wants, but as they are never activated via systemd, these Wants lines never gets executed. Check systemctl status network-online.target true and maybe the reason for https://bugzilla.redhat.com/show_bug.cgi?id=1023788 https://bugzilla.redhat.com/show_bug.cgi?id=891137 https://bugzilla.redhat.com/show_bug.cgi?id=1023788 is clearly introduced by systemd at F20/RHEL7 and leads to completly frozen terminals while rebooting a F20/RHEL7 remote machine using network.service because NM on a static config is useless [root@srv-rhsoft:~]$ systemctl status network-online.target network-online.target - Network is Online Loaded: loaded (/usr/lib/systemd/system/network-online.target; static) Active: inactive (dead) Docs: man:systemd.special(7) http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget [root@srv-rhsoft:~]$ systemctl start network-online.target [root@srv-rhsoft:~]$ systemctl status network-online.target network-online.target - Network is Online Loaded: loaded (/usr/lib/systemd/system/network-online.target; static) Active: active since Mi 2014-01-01 22:24:25 CET; 1s ago Docs: man:systemd.special(7) http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget 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] [RFT] DHCPv4 support in networkd
Am 02.01.2014 13:55, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436 because this explains why i sometimes see firewall logs in the company network where all severs are blocking private ranges as spoofed address i would be thankful not starting the same odd behavior with linux clients this is also really funny if it leads calling your ISP names because it appears that the managed router let public IP's connect to the fileserver in a non-public range until you find out that was the public home IP of a employer please don't do that - thank you! 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] [RFT] DHCPv4 support in networkd
Am 02.01.2014 16:29, schrieb Tom Gundersen: Hei Reindl, On Thu, Jan 2, 2014 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.01.2014 13:55, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 12:56 PM, Holger Schurig holgerschu...@gmail.com wrote: AFAIK Mac OSX does a trick here Yeah, and we should do the same: http://tools.ietf.org/search/rfc4436 because this explains why i sometimes see firewall logs in the company network where all severs are blocking private ranges as spoofed address i would be thankful not starting the same odd behavior with linux clients this is also really funny if it leads calling your ISP names because it appears that the managed router let public IP's connect to the fileserver in a non-public range until you find out that was the public home IP of a employer please don't do that - thank you! I'm not sure I fully understand what you are referring to. Did you read the RFC? Could you explain a bit more precisely what setups causes problems under that RFC? the problems are that if someone comes back with his Apple notebook this crap starts to using the old ip-address and triggering all sorts of alarms, firewall-rules and so on at least in one case i called our ISP names because i did not imagine that any operating system may be that stupid to use the public IP of the users home-internet to re-connect to the fileserver and after that failed ask our DHCP for a correct IP 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] [RFT] DHCPv4 support in networkd
Am 02.01.2014 16:41, schrieb Tom Gundersen: On Thu, Jan 2, 2014 at 4:37 PM, Reindl Harald h.rei...@thelounge.net wrote: the problems are that if someone comes back with his Apple notebook this crap starts to using the old ip-address and triggering all sorts of alarms, firewall-rules and so on Hm, sounds odd. This protocol is precisely meant to avoid that sort of problem (by detecting whether or not you are connecting to the same network). I heard that some old Apple devices used a more naive protocol that would indeed just reuse the old IP... When did you last experience this? Any clue about what hardware/software version it was causing the problem? 2013, OSX 10.6, the first Mac Book Pro generation not supported by OSX 10.6 as far as i know, one bought a few months later would be supported given that this machines are not that old and expensive they will exist longer here and there (yes i know about the securtiy nightmare but in that context OSX should be banned at all) 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] systemd-udevd Oops
Am 14.01.2014 15:03, schrieb Cristian Rodríguez: El 14/01/14 09:52, Mark Hounschell escribió: Well, the systemd/udev README file from 208-15.1: yeah, one thing is what systemd upstream requires and a completely different one is what openSUSE can/will support or allow. It is not just systemd really, other applications or libraries may require particular features only found in a kernel of either the same major version or something close.. let's say.. openSUSE 13.1 has 3.11 , some app might require 3.10 or 3.9, things might start to very subtle fail, particularly if error handling is shaky or we might sneak-in distribution or OS specific patches that just assume you run the product's minimal kernel version or later which application should this be? please state a real-world example - the Kernel usually does not break userland Fedora 18 as example was released with Kernel 3.6 and is now at EOL on 3.11.10 Fedora 17 as example was released with Kernel 3.3 and at EOL had 3.9.10 you can even use the 3.11.10-100.fc18.x86_64 on F17 in case you have a dying platform on a machine and want at least kernel fixes signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl reboot/shutdown freezes client
can someone please have a look why starting with Fedora 20/RHEL7 and systemd-208 after typing systemctl reboot no longer waits until sshd is closing the client connection resulting in a completly frozen VT ignoring CTRL+C and waiting for KeepAlive timeout https://bugzilla.redhat.com/show_bug.cgi?id=1023788 systemd-208-11.fc20.x86_64 http://koji.fedoraproject.org/koji/buildinfo?buildID=491024 still the same problem 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] systemctl reboot/shutdown freezes client
Am 15.01.2014 03:57, schrieb Andrey Borzenkov: В Wed, 15 Jan 2014 02:54:16 +0100 Reindl Harald h.rei...@thelounge.net пишет: can someone please have a look why starting with Fedora 20/RHEL7 and systemd-208 after typing systemctl reboot no longer waits until sshd is closing the client connection resulting in a completly frozen VT ignoring CTRL+C and waiting for KeepAlive timeout If you mean - you ssh into VM, then reboot VM and your client ssh hangs - you can use ~. to quit it. You should always be prepared for something like this - nobody can guarantee your server or network won't die in the middle of session. that is not the point, what someone *can* do does not fix bugs the point is that it now *predictable* hangs and in case the VM is running on the same machine i am sitting in front of it is very unlikely that the newtwork dies nor does it in case of a LAN with bonding devices ___ the opposite is true: SSH-CLient: KeepAliveyes ServerAliveCountMax 10 ServerAliveInterval 20 SSH-Server: KeepAliveyes ClientAliveCountMax 10 ClientAliveInterval 20 hence i can even reboot the VPN server i am connected through to a different one wihtout lose touch because of KeepAlive, but if the first systemd does after reboot/shutdown command is killing my network session *that* hangs and KeepAlive hardly works between reboots of the ssh-server belonging to that session that behavior may result in all sorts of troubles in case of network-mounts not properly unmounted and what not else - a bug is a bug and stays a bug ___ https://bugzilla.redhat.com/show_bug.cgi?id=1023788 systemd-208-11.fc20.x86_64 http://koji.fedoraproject.org/koji/buildinfo?buildID=491024 still the same problem 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] systemctl reboot/shutdown freezes client
Am 15.01.2014 16:47, schrieb Reindl Harald: Am 15.01.2014 16:37, schrieb Holger Schurig: Try systemctl --force reboot. The --force will kill the processes, which (for me) closes the incoming ssh session that indeed works interesting question: what has changed in the latest systemd-releases because this behavior is new and what negative impact may the --force switch have because it's not the default ok, answered by reading the manpage --force is nothing you want on a production server only because a behavior change in sshd due shutdown / reboot If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the reboot. 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] Allow stop jobs to be killed during shutdown
Am 24.01.2014 16:03, schrieb Lennart Poettering: It is our job to shutdown all services cleanly. A number of services needs this, since they need to bring their files into a safe state before quitting, and mark them as offline. We cannot just drop that. Note however, that we add have timeouts on all service shutdown commands, so when some service hangs it will be forcibly aborted with SIGKILL after 90s. That all said, you can just shutdown with systemctl poweroff -f instead of normal systemctl poweroff. This will still bring the file systems in order and things, but wil not bother with shutting down system services cleanly, but simply SIGTERM and SIGKILL them after a much shorter timeout. However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 and https://bugzilla.redhat.com/show_bug.cgi?id=1023788 should be fixed much faster or never make it in a stable release 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] Allow stop jobs to be killed during shutdown
Am 24.01.2014 18:43, schrieb Lennart Poettering: On Fri, 24.01.14 17:10, Colin Guthrie (gm...@colin.guthr.ie) wrote: 'Twas brillig, and Tom Horsley at 24/01/14 15:44 did gyre and gimble: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order. I didn't ask for any change to any default, I just asked for users to be able to make the shutdown process proceed when they have more information than systemd has about the chances of success of some random stop job. Without that, what you *will* get is people pulling the power plug which has a vastly greater chance of screwing up the system than not waiting for a single stop job. Perhaps just displaying the timeout would be useful here. We do that. Michal's eye of sauron animation is shown as soon as something blocks too long, and the name of the unit we are waiting for is shown. but there is nothing saying how long the timeout remains displaying the timeout means a value in seconds 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] Allow stop jobs to be killed during shutdown
Am 24.01.2014 19:26, schrieb Michael Biebl: 2014/1/24 Lennart Poettering lenn...@poettering.net: Yupp, Michal had the same idea, that's why there is the eye-of-sauron animation in place... Ah, good to know. That's a start. I guess my systemd version (v204) is simply too old then? Is this animation shown irregardless of whether one has booted with quiet or not? dunno - quiet is the first i disable Does it require plymouth? for sure not rd.plymouth=0 plymouth.enable=0 on all machines i maintain (around 40 currently) as well as [root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf omit_dracutmodules+=plymouth but as said - a value in seconds would be interesting in case of a service with a large timeout it really matters and in doubt you dunno how large the timeout of the hanging one is signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: Allow stop jobs to be killed during shutdown
uhm the below is the result of people using reply-all on lists and the other side filters out duplicates caused by leading the off-list reply survives if it was faster Original-Nachricht Betreff: Re: [systemd-devel] Allow stop jobs to be killed during shutdown Datum: Fri, 24 Jan 2014 18:59:56 +0100 Von: Reindl Harald h.rei...@thelounge.net An: Lennart Poettering lenn...@poettering.net Am 24.01.2014 18:53, schrieb Lennart Poettering: On Fri, 24.01.14 18:45, Reindl Harald (h.rei...@thelounge.net) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order. I didn't ask for any change to any default, I just asked for users to be able to make the shutdown process proceed when they have more information than systemd has about the chances of success of some random stop job. Without that, what you *will* get is people pulling the power plug which has a vastly greater chance of screwing up the system than not waiting for a single stop job. Perhaps just displaying the timeout would be useful here. We do that. Michal's eye of sauron animation is shown as soon as something blocks too long, and the name of the unit we are waiting for is shown. but there is nothing saying how long the timeout remains displaying the timeout means a value in seconds That delay is set to 5s the timeout is TimeoutStopSec or TimeoutStopSec Oh, and where I wrote eye of sauron I meant cylon irrelevant - whatever it is it says waiting for service xyz but it does *not* say how long it waits until it will give up the interesting value is TimeoutStopSec-TimeWaiting 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] Allow stop jobs to be killed during shutdown
Am 24.01.2014 19:44, schrieb Zbigniew Jędrzejewski-Szmek: Is this animation shown irregardless of whether one has booted with quiet or not? With quiet the [OK] lines are not shown, so no, it only works without quiet one more case why the shiny graphical boot does only harm in case of troubles and the average user is not aware that his system could be more verbose than Windows/OSX at boot the advanced user disables rhgb / quiet but could do this also only in case things seem to be broken while the ordinary user is facing a (maybe, or maybe not) hanging system not talking to him 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] Allow stop jobs to be killed during shutdown
Am 24.01.2014 20:01, schrieb Andrey Borzenkov: В Fri, 24 Jan 2014 19:44:08 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Fri, Jan 24, 2014 at 07:26:48PM +0100, Michael Biebl wrote: 2014/1/24 Lennart Poettering lenn...@poettering.net: On Fri, 24.01.14 18:18, Michael Biebl (mbi...@gmail.com) wrote: Making the shutdown more verbose in such a situation would imho be a good idea, showing a countdown or something like that with a note for which service systemd is currently waiting to be shutdown. I completely agree with Tom here: In situations where on shutdown (or boot for that matter) the system blocks for longer then 30-60 secs and no feedback at all most people will simply assume the system got stuck and do power-reset. Yupp, Michal had the same idea, that's why there is the eye-of-sauron animation in place... Ah, good to know. That's a start. I guess my systemd version (v204) is simply too old then? Is this animation shown irregardless of whether one has booted with quiet or not? With quiet the [OK] lines are not shown, so no, it only works without quiet. Is it possible to automatically switch to more verbose mode as soon as any problem is seen (like service timeout)? too late, after the timeout is reached it continues the users problem is the silent waiting *before* the timeout 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] customized shutdown service needed
Am 29.02.2012 17:16, schrieb Lennart Poettering: On Sun, 26.02.12 19:13, Reindl Harald (h.rei...@thelounge.net) wrote: the ExecStop is called but systemd DOES NOT wait until it is finished leading to all virtual machines are killed hard while systemctl stop vmware-default.service does supsend them perfectlly as long it is not combined with any sort of shutdown systemd waits for ExecStop= to finish before executing later jobs (well, subject to a timeout, of a couple of minutes). What really matters is that you order your service before/after the right things, and be aware that: a) the stop order is implicitly the reverse of the start order b) if a job is started and another one stopped and they are ordered against each other, then the stop is executed first, and the start executed second, regardless which kind of ordering is actually configured by the way - somewhere around Fedora 18 without change anything on my side systemd no longer kills ExecStop and so suspending VM's, meaning this was clearly a systemd bug as i reported it ExecStartPost=-/usr/bin/su -c /scripts/vmware/vm-default-start.sh vmware ExecStop=-/scripts/vmware/vm-suspend-all.sh [root@srv-rhsoft:~]$ cat /scripts/vmware/vm-suspend-all.sh #!/usr/bin/bash if [ -x /usr/bin/vmrun ] ; then for i in `pidof vmware-vmx` ; do VMX_PATH=`ps -p $i -f | sed -ne '/vmware/s/.* \(\/.*\.vmx\)/\1/p'` /usr/bin/logger -t vmware SUSPEND: $VMX_PATH /usr/bin/vmrun suspend `ps -p $i -f | sed -ne '/vmware/s/.* \(\/.*\.vmx\)/\1/p'` 2 /dev/null /usr/bin/logger -t vmware SUSPENDED: $VMX_PATH done fi /usr/bin/bash /vmware/permissions.sh exit 0 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] Allow stop jobs to be killed during shutdown
Am 25.01.2014 18:09, schrieb Marcos Mello: Koen Kooi koen at dominion.thruhere.net writes: [snip] To make matters worse, the cylon eye isn't displayed when you boot with 'quiet' in your kernel command line. quiet systemd.show_status=1 shows the gracious Cylon eye so that should be default and extended by a visible counter manually to add boot-params are useless for the normal user the advaned one is not using quiet at all 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] Malicious tests?
Am 27.01.2014 12:30, schrieb Tom Horsley: Sadly simple containers with little real world units seem to avoid the problems. But I'm sure there will be some kind of fix for this over the next week or so. But my example doesn't have any units at all :-). I issue two disable commands in a row for units that don't even exist. I have no idea why it would feel the need to do a daemon-reload when I disable a non-existent unit there is a deeper problem a simple reload should not lead to reach any target which is already reached for hours, so reload does way more as expected [root@rh:~]$ /var/log/messages; systemctl daemon-reload; sleep 3; systemctl daemon-reload; cat /var/log/messages Jan 27 12:36:35 rh systemd[1]: Mounted Configuration File System. Jan 27 12:36:35 rh systemd[1]: Reached target Sound Card. Jan 27 12:36:35 rh systemd[1]: Found device /sys/devices/virtual/block/md0. Jan 27 12:36:35 rh systemd[1]: Found device /dev/md0. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-name-localhost.localdomain:0. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-uuid-1d691642:baed26df:1d197496:4fb00ff8. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-label/boot. Jan 27 12:36:35 rh systemd[1]: Found device /sys/devices/virtual/block/md2. Jan 27 12:36:35 rh systemd[1]: Found device /dev/md2. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-name-localhost.localdomain:2. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-uuid-ea253255:cb915401:f32794ad:ce0fe396. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-label/data. Jan 27 12:36:38 rh systemd[1]: Mounted Configuration File System. Jan 27 12:36:38 rh systemd[1]: Reached target Sound Card. Jan 27 12:36:38 rh systemd[1]: Found device /sys/devices/virtual/block/md0. Jan 27 12:36:38 rh systemd[1]: Found device /dev/md0. Jan 27 12:36:38 rh systemd[1]: Found device /dev/disk/by-id/md-name-localhost.localdomain:0. Jan 27 12:36:38 rh systemd[1]: Found device /dev/disk/by-id/md-uuid-1d691642:baed26df:1d197496:4fb00ff8. 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] Allow stop jobs to be killed during shutdown
Am 28.01.2014 05:27, schrieb Zbigniew Jędrzejewski-Szmek: after the timeout is reached it continues the users problem is the silent waiting *before* the timeout Done. After a job has been running for more than 5s, or a failure occurs, cylon eye will be shown. Also status will be printed until bootup or shutdown is completed. systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ) Detected virtualization 'systemd-nspawn'. [FAILED] Failed to start bad.service. See 'systemctl status bad.service' for details. Starting Permit User Sessions... [ OK ] Started Cleanup of Temporary Directories. [ OK ] Started Permit User Sessions. Starting Console Getty... [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Fedora release 21 (Rawhide) Kernel 3.13.0-0.rc5.git0.2.fc21.x86_64 on an x86_64 (console) fedora-21 login: root sounds good - thanks for all that fine-tuning! 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] systemd shutdown problem on openSuSE 13.1 with NFS mounted user home
Am 04.02.2014 11:31, schrieb Rainer Krienke: I am experiencing problems on openSuSE 13.1 systems using systemd, iff this system uses NFS mounts for the users home directory mounted by automount. Regular 13.1 installations with local user home directories just work fine. The problem is, that when trying to shut the system down this shutdown process hangs for a very long time ( 5min). After 5 Min I went away , when I came back an hour later the shutdown had succeded. To investigate the problem I created a systemd debug log of such a shutdown you can download here: http://userpages.uni-koblenz.de/~krienke/tmp/systemd/shutdown-debug.log My problem is to extract really useful information about the real reason for the hanging shutdown. My thoughts are, that perhaps systemd already tries to umount NFS filesystems when there are still user processes active on them and thus the umount hangs. In the default openSuSE 13.1 autofs.service file there is no dependency on user sessions (only this: After=network.target remote-fs.target ypbind.service) and perhaps this is the reason for my problem. But I do not know how I could tell systemd to stop automount only after the users session has been terminated and thus his NFS home directory can be umounted by stopping automount most likely the same as, both introduced with recent systemd and not present in Fedora 19 https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1023788 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] [PATCH] udev: Adding zram to inappropriate block device
Am 06.02.2014 18:45, schrieb Greg KH: On Thu, Feb 06, 2014 at 04:54:59PM +, Jóhann B. Guðmundsson wrote: On 02/06/2014 03:39 PM, Greg KH wrote: Right now you have to decide before loading the module how many devices you want. And also when trying to use a device (any device), you have to look for one. The same issues as with loop. Given that the code doesn't have the ability to dynamically add/remove devices, I think we are stuck with this, right? This may come as a completely stupid question but if the code is expected to be able to dynamically add/remove devices should not upstream ( kernel ) nack inclusion of zram until it does? I don't think the code is expected to be able to do that, have you looked at it and seen where it does? please re-read both posts in the last one clearly a not fails fixed version: This may come as a completely stupid question but if the code is *not* expected to be able to dynamically add/remove devices should not upstream ( kernel ) nack inclusion of zram until it does? 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] /run needs to be mounted? ugh.
Am 11.02.2014 17:29, schrieb Andrey Borzenkov: В Tue, 11 Feb 2014 17:20:15 +0100 Jason A. Donenfeld ja...@zx2c4.com пишет: On Tue, Feb 11, 2014 at 5:15 PM, Dave Reisner d...@falconindy.com wrote: I don't think there's any change needed here. The interface states: The initrd should mount /run as a tmpfs. And sure enough, this isn't a requirement, but there's many valid reasons to do this. Ahh, okay. I suppose what I'm wondering is what the advantages are to mounting /run (if the remaining interfaces in the list aren't used)? It looks like mounting /run occurs pretty soon in core/main.c. Could it be that the only advantages of mounting /run early on are for using the more advanced systemd initrd interfaces, such as giving control back during shutdown? Or are there benefits in doing this even for the most minimal of initrd? /run is used to pass state between initrd and system for such components as udev or mdadm. I do not know how your initramfs implementation works and whether it is using udev, but if you support root on MD, you likely will need /run in context systemd maybe, in context MD not the machine in front of me running F20 with systemd has root on RAID10 originally installed with F14 before /run and systemd existed in the setup signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
