Re: [systemd-devel] Xorg or Wayland Environment
On 19/09/2021 13.11, Ed Greshko wrote: OK.. I think I see the problem now. I don't need Environment=. But the issue is that, I assumed, "plasma-core.target" would be reached only after a user logged in to plasma. I was wrong and the user's service is run earlier when the login screen appears. I need to find a way such that the service only runs when a user logs on to the plasma GUI. I think you want to use autostart files rather than systemd service units. Autostart files are intended to do this and allow you to specify upon which phase of KDE startup they should be executed. -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On 14/09/2021 13.36, Lennart Poettering wrote: Heya! Some of the systemd developers have been discussing switching systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop support for older OpenSSL versions, as well as any GNUTLS/libgcrypt support. As you might have noticed OpenSSL 3.0 has been released recently, and for the first time resolves the GPL2 license incompatibility mess comprehensively, which opens this door to us. I am not an active developer. Nonetheless I would second this, provided the use of OpenSSL does not lead to security vulnerabilities in core non-optional system parts on systems built with the systemd project's outputs. -- Rudd-O https://rudd-o.com/ OpenPGP_signature Description: OpenPGP digital signature
Re: [systemd-devel] [systemd.service] TCP listen port conflict resolution / explicit erring?
On 05/01/2017 03:57 AM, Alec Taylor wrote: > Wrote some scripts to generate systemd .service files and start-up > those services. > > Currently just for some REST APIs, but soon will include distributed > systems also. > > I set the TCP listen port variable that is used by my .service like > so: `Environment=PORT=4200` > > To get PATH to work nicely, my `ExecStart` begins with: > /bin/bash -c 'PATH=bash -c PATH=$PREPEND_PATH:$PATH > > (would appreciate an alternative to launching a new shell there also!) > > *Is there a systemd trick of explicitly erring on TCP listen-port > conflicts? > > * > And/or should I just write a parser that loops through all .service's > and checks the `PORT=` and raises on conflict? You are meant to use socket units for what you are doing. Look it up. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On 09/26/2016 09:27 AM, Oliver Neukum wrote: > On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote: >> RTFM - when you don't say "nofail" it's ecpected to be crucial >> >> your entry says it's crucial > That in turn raises the question why the default should be different > than what is used in earlier systems. Earlier systems defaulted to nofail behavior. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On 09/26/2016 10:31 AM, Reindl Harald wrote: > > > Am 26.09.2016 um 11:27 schrieb Oliver Neukum: >> On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote: >>> >>> RTFM - when you don't say "nofail" it's ecpected to be crucial >>> >>> your entry says it's crucial >> >> That in turn raises the question why the default should be different >> than what is used in earlier systems > > because earlier systems (sysvinit) hat no concept like emergency mode > as they where a lousy bunch of scripts where you ended in case of a > crucial disk failing in a undefined state? > > because earlier systems had no concept for "nofail" or "fail" at all Yes, they did. Boot would fail if a device in fstab was set to mount on boot (option "noauto" absent) and it was not present during boot. This is precisely why nofail is the default. Sergei is right. RTFM. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Help with boot time debugging
Hello folks! I'm developing a Dracut module and I need to know how to go about showing what processes run by systemd during boot are saying. This is for https://github.com/Rudd-O/zfs-fedora-installer . For example, I have this one that happens during boot: "Starting dracut cmdline hook" I want to show on the console what the cmdline hook might have spat to standard output. I want every single process that produces stdout/stderr/logging output to show me that output on the console. The boot time option systemd.journald.forward_to_console simply did not work (my console is a ttyS0). What gives? Thanks in advance. -- Rudd-O http://rudd-o.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On 04/12/2016 02:26 AM, Xen wrote: > Greg KH schreef op 12-04-16 00:14: >>> Also, since the current scheme puts usb devices in a slightly different >>> format you can identify them from the name. >>> >>> You are right in saying that that would cause a list that changes as it >>> is getting populated. But onboard/builtin devices should definitely all >>> be scanned before networking is initialized right? >> Not true at all, drivers are loaded whenever, at pretty much random >> times, when ever the hardware is found by the kernel. It's >> non-deterministic and you never know when it's done for some busses >> (like USB). > That is completely nonsensical because it would imply that some network > device could be initialized 2 hours after the system had booted. Greg KH is completely correct -- that can totally happen. But it's clear that rational, calm, evidence-based arguments aren't swaying you. So I'll try asking a question instead: 1. Why don't you follow the documented procedure to disable the feature you hate? What's it with posting on the list repeatedly about it? 2. The new netdev naming system has made the lives of many people much better (me included). Why should /your/ preference -- which would instantly make us all worse off -- become the new default, over our well-served needs? -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about mount unit generators
On 08/03/2012 06:48 PM, Lennart Poettering wrote: >> Thus my question: >> > >> > Would it be correct to say that the generator I wrote absolutely does >> > not need to calculate parent file system dependencies, because some >> > black magic inside systemd / systemctl knows to figure out the parent >> > file system dependencies thus guarantees mounting in the right order?? >> > >> > Thanks in advance. > Yes, as Zbigniew pointed out, we implicitly and always add the > inter-mount deps for mounts that lie below other mounts. Thread necromancing. Thanks for this reply, as it was the thing that enabled me to write the right Dracut systemd integration code for ZFS. You rock. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/26/2015 07:28 PM, Reindl Harald wrote: > > my infrastructure is most likely better managed than anyone leses So says the person with a limited perspective and a refusal to learn modern tools and processes. > > you are not in the position to give orders Did you just forget that it was YOU giving me an order, and not the other way around? Who are, you? https://reddit.com/r/KenM/ ? You gotta be Ken M. > > bullshit - my portfolio of skills goes far above things you can imagine, https://reddit.com/r/iamverysmart/ > bla Typical. > > impressive what a arrgoant asshole you are while talking about "Arrogant" is the guy who refuses to accept new ways of doing things, because he thinks that the way he does things is perfect and damn those youngsters running on his lawn with their hand-holding helpers. (That'd be you.) > "treated other people badly here" - maybe you did not grok it - my > main job is software-developer *on top* of the perfect working > infrastructure and before people like me knowing to hanle and develop > backends and frontends for hundrets of customer over any service level > hell freezes over With the two nines reliability you give them on account of not being able to do outage-free reloads of Apache... Ouch -- Rudd-O http://rudd-o.com/ 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] Policy Routing on a machine using systemd-networkd
On 12/20/2015 01:52 PM, Marc Haber wrote: > *nudge* > > Is there really no option about this rather common issue? I too am interested in more info about this. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/26/2015 07:12 PM, Reindl Harald wrote: > you said "reload would be possible again" Let me spell that sentence out in context: If you stopped using EnvironmentFile and starting actually assembling proper configurations using a configuration management tool, then the command "systemctl reload httpd.service" would work properly again, as opposed to how it is broken now in your own systems. > - maybe you have trouble express yourself proper Look who's talking. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/26/2015 07:06 PM, Reindl Harald wrote: > people needing handholding - bah See, your problem is more a limited mindset / perspective problem. From your attitude, you believe it's demeaning to use the proper tool for the job, taking it as a point of pride that you have deficient and obsolete tools at your disposal. From your attitude, you also believe everyone else is obligated to maintain and support ugly workarounds that result in broken systems (e.g. no properly working reload). > - for version control etckeeper does a damn good job, Your attitude also tells me that you don't understand the value of proper version control, with branching, merging, and possibly code reviews. In other words, that you don't see your infrastructure and configuration as something to be managed as professionally as any other software engineering project. > vhsot-configs are generated by templates Guess how Ansible works. > and for the basic host configuration i don't need tools since i got a > brain You'll be needing that brain since no configuration management tool generates those base configs for you. > > so do me a favour and creep away with your attitude press reply days > and weeks later to every single post on a topic No, I don't think I will be taking orders from you. Here's what I think happened to you in the past. You learned a bit of bash, SysVinit, and etckeeper. You decided this was going to be THE THING for you -- your ultimate portfolio of skills -- forever for the rest of your life. Then us DevOps and systemd folks came crashing into your obsolescence party. You resent that -- it's exceedingly obvious from your attitude that you do. That's why you've treated other people badly here. It's time to evolve. Arguably, it was time a few years ago. Dust up your learning cap and re-learn how things are done now. Or pretty soon, /you/ will be what becomes obsolete. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/20/2015 01:30 PM, Marc Haber wrote: > > How would I do the equivalent of systemctl edit with a declarative > configuration management tool like puppet? systemctl edit on a host copy the file to your puppet server (ugh, don't use puppet, use ansible) deploy file across hosts -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/26/2015 06:58 PM, Reindl Harald wrote: > > > Am 26.12.2015 um 19:52 schrieb Manuel Amador (Rudd-O): > > i am capable to write my configs by hand withoput babysitting by > Puppet or something else What a macho man! Guess what: those of us who use configuration systems also write configs by hand. We just aren't tied to deficient workarounds like the one you're clinging so hard to. > - why sould i introduce security holes and making things more complex > than needed all over my environment when i know what i am doing? I never told you to use Puppet. I wouldn't use it myself. The Ansible configuration I wrote here in another email for you, happens to work perfectly for your use case, does not require to install any sort of new daemons or services or cronjobs, and has the benefit that you can version it like any other normal piece of code (because configuration IS code, just not executable code). -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/26/2015 06:58 PM, Reindl Harald wrote: > > uhm - "EnvironmentFile" don't change often and so reload is possible > all the time I never said you couldn't reload. I said that reload would not enact your environment file changes. Are you having trouble understanding what I wrote, or is it the dogma talking? -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/16/2015 09:47 AM, Reindl Harald wrote: > because i know how to configure servers and don't need handholding > tools since i develop my own admin backends for many years and > services helping on repeatly needed taks but don't chain me to a > limited subset of the supported options Ah. So the others were right -- you don't want to learn something new because you're so set in your ways, you have your own in-house stuff that you don't want to replace by learning something new. Even the expression you use for professional systems -- "handholding tools" -- reveals your contempt for what you don't know. Sigh. This is the perfect picture of the systemd hater. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/16/2015 09:47 AM, Reindl Harald wrote: > "normal people" - what's wrong with you? Us "normal people" use configuration management systems to properly do what you do with ugly hacks. It's 2015. cfengine is not the only game in town. Check my last email. It took me two minutes to write an entire configuration system that you could use today, to solve your problem *properly and with proper change management* / version control. Environment files... bah. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/11/2015 02:59 PM, Reindl Harald wrote:
> and that's exactly what i don't want to do for damned good reasons
>
> * in the past i started httpd with type=forking
> * it was just "/usr/sbin/httpd $OPTIONS"
> * switch to "Type=simple" was change the untit in our own
> maintained rpm-package and add "-D FOREGROUND" too
Hi. Here is how you solve the problem with the right tool for the job:
---
# configapache.yml
hosts: apacheservers
sudo: True
tasks:
- name: configure apache
template:
dest: /etc/httpd/conf/httpd.conf
src: httpd.conf.jinja2
notify: reload apache
- name: copy testserver stuff
copy:
dest: /etc/httpd/conf/local/testserver.conf
src: testserver.conf
notify: reload apache
handlers:
- name: reload apache
service: httpd state=reloaded
---
# httpd.conf.jinja2
...standard config...
{% if apache.testserver %}
Include "conf/local/testserver.conf"
{% endif %}
---
# host_vars/apache1.yml
apache:
testserver: True
---
# hosts
apache1
apache2
apache3
postfix1
postfix2
[apacheservers]
apache1
apache2
apache3
---
# your prompt
ansible-playbook -v configapache.yml
There you go -- a quick way to do proper Apache configuration without
dicking with EnvironmentFiles that *actually preserves the ability to
reload Apache with no downtime!*
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/10/2015 03:20 PM, Reindl Harald wrote: > > Apache: > > Include "conf/local/testserver.conf" > > > and now you can use the same systemd-unit on a dozens of machines and > include specific config snippets WITOUT touch the systemd-unit or > *anything* else in the apache configuration This sounds like you're aching to use something like Ansible or SaltStack. Dozens of machines, that means you're going to be managing dozens of files. Use a proper configuration management system. Also note that with your defines "system", service apache reload stops working. If you wrote those things /properly in the config files/ (like you could do with Ansible or SaltStack), then no-downtime reload becomes possible again. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/26/2015 06:44 PM, Reindl Harald wrote: > > > Am 26.12.2015 um 19:41 schrieb Manuel Amador (Rudd-O): >> On 12/23/2015 10:40 PM, Reindl Harald wrote: >> >> Nobody is forcing you to change anything from your configuration > > Johann would if he had the power to do so Aren't you glad he doesn't? > >> though environment files are shit for configuration (the reasoning of >> which has already been explained, but you don't seem to be listening) > > i DON'T CARE about reload because "EnvironmentFile" don't change every > second Yes, you've established that, for your use case, shit config files are fine. Nobody is taking away your candy, chillax. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/10/2015 11:42 AM, Simon McVittie wrote: > The approach I try to follow in dbus is that options that should be > changed by another package (such as default security policies) go in a > configuration file, or more recently a file in /usr/share; options that > should be changed by the sysadmin (such as security policies and > resource limits) also go in a configuration file; but system-integration > options (such as "use syslog" or "use systemd for activation") are > command-line options that can be forced to their > correct-for-this-distribution values by the ExecStart line in the > systemd unit, LSB init script or whatever. Unfortunately dbus doesn't > always follow this rule for historical reasons - is a > configuration-file option, but it shouldn't be. I like what the Genode folks are doing these days to solve this problem. It truly is brilliant and I wish Linux had anything like it: When a program starts, its creator "container" creates a ROM dataspace (a chunk of read-only memory that gets mapped into the memory space of the program) and then passes the dataspace as a capability to the program. The program then reads its configuration from the dataspace. When the configuration file on disk is changed, the creator notices, creates a brand new ROM dataspace, and pushes it to the program via IPC. The program then has automatically mapped the new ROM dataspace into its address space, but the new ROM dataspace is not active -- it is up to the program to do whatever is necessary to make the new ROM dataspace take effect, whenever it decides to do so. All of this works without restarts, completely transparently and automatically, and it's actual library code that is automatically reused among ALL Genode programs, uses actual capability-based IPC, and is entirely secure in a way no Linux program can be. Meanwhile, we're still in 1980 dicking around with EnvironmentFiles and FlagFiles and such bullshit. But I do think that Genode has a vaiuable lesson here. If, say, systemd gained the capability to "compile" configurations and push them to daemons via memfd, and daemons learned how to catch those memfds and reconfigure themselves as they are received -- a similar, but less secure concept than what Genode does -- then we would have invented the perfect reload pattern. Heck, systemd could even compile that stupid EnvironmentFile and ship it to the daemon without having to do any sort of evaluation on ExecStart... and perhaps even automatically ship the compiled configuration as soon as its source is detected to have changed, much like Genode does today. Ah, a man can dream. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/23/2015 07:30 PM, Alex Crawford wrote:
> We use it within CoreOS to allow the user to inject dynamic data into the
> service. For example, you may have a service like this:
>
> $ cat etcd.service
> [Unit]
> Requires=metadata.service
> After=metadata.service
>
> [Service]
> EnvironmentFile=/run/coreos/metadata
> ExecStart=/usr/bin/etcd --public-ip=${COREOS_PRIVATE_IPV4}
>
> where "metadata.service" populates /run/coreos/metadata with a bunch of info
> about the system (like Facter from puppet). The user can then pick and choose
> the appropriate variables to use (maybe they need the public address instead)
> and override the ExecStart in a drop-in.
This breaks reload.
But, of course, if etcd does not support reload, and it's planned that
one etcd node will fail to serve its clients while it is down /
restarting, then it's a fine use of EnvFile.
--
Rudd-O
http://rudd-o.com/
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/21/2015 10:29 PM, Marc Haber wrote: > The problem is that a minoriy of concepts and the attitude of the > makers make working with systemd a constant source of increased blood > pressure and a strong urge to break something expensive just to get > rid of the aggression. For that, there's therapy. Other human beings are not your punching bags. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/21/2015 09:41 PM, Marc Haber wrote: > This is exactly why systemd is the top one most hated piece of open > source software. We are not here to be educated about the one and only > right way of doing things. Actually, you hate systemd because you don't like that systemd forces you to learn new things. One of those things is how unmaintainable environment and shell scripts really are, and how they often cause problems on production (the reload problem is just one of them). But, since you don't like to be told that the things you prefer are shit, you instead project your anger on systemd and its developers. Grow up. -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/23/2015 10:40 PM, Reindl Harald wrote: > why should i change anything in *my* configuartion *because* you don't > like it? Nobody is forcing you to change anything from your configuration. Even though environment files are shit for configuration (the reasoning of which has already been explained, but you don't seem to be listening). -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/23/2015 08:18 PM, Reindl Harald wrote: > and what's the difference between a config file or "EnvironmentFile" > besides you like the one for whatever reason more while both are > config files? It has already been explained that certain operations will not cause the EnvironmentFile contents to propagate to the services run by the unit. Reload is one of those operations. Do you need a deeper explanation? -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On 12/23/2015 07:48 PM, Lennart Poettering wrote: > I see no reason why systemd should be involved with this. Just make > etcd a proper daemon, and read its config data directly, rather then > serializing it into the command line. > > Lennart Reading from environment / flagfiles / command line is super popular these days, whether it be because Google did it that way and now ex-Googlers are popularizing the pattern, or because of the 12-factor application fad (which I admit, has quite a few merits). This is why developers are frequently using systemd with EnvironmentFile these days. Of course, this breaks reload... but almost nobody is writing reload code in their daemons these days anymore. -- Rudd-O http://rudd-o.com/ 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] Calculating Web page loads accurately with systemd-nspawn's network-veth & Xorg
On 08/23/2015 07:17 AM, Kai Hendry wrote: > On Sun, 23 Aug 2015, at 10:05 PM, Mantas Mikulėnas wrote: >> Try adding --bind=/tmp/.X11-unix, for the named X11 sockets. > Ah! Thank you Mantas. I logged this tip on http://dabase.com/e/12009/ > Note that this allows the containerized app to punch through the container and into the X server. -- Rudd-O http://rudd-o.com/ 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] cannot view my own logs?
I'm trying to audit my user logs on my system but journalctl shows nothing, saying No journal files were opened due to insufficient permissions. journald has created these files: total 587,776 drwxr-xr-x 2 root root4 Oct 8 22:13 . drwxr-xr-x 3 root root3 Oct 8 22:09 .. -rw-r- 1 root systemd-journal 3,891,200 Oct 9 00:45 system.journal -rw-r- 1 root systemd-journal 3,792,896 Oct 9 00:45 user-501.journal why isn't it creating the files with the proper permissions? Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Small tool to spawn programs in graphical sessions from non-graphical ones
D-BUS. XAUTHORITY. Other session variables (including KIO / GPG password manager / et cetera). You get the use of none of these things in your cron-started programs... unless you use my program. Some programs even flat out refuse to start, actually. Thus, why I wrote my program. On 08/31/2013 05:28 AM, killermoehre wrote: Am 31.08.2013 11:09, schrieb Manuel Amador (Rudd-O): Based on systemd's related sibling loginctl, I managed to accomplish the holy grail of the 90's: get Amarok to play music on my desktop sessiom from a crontab (motivated by the missus' desire to have an alarm in the home theater that requires her to walk downstairs, to adapt to her polyphasic sleep): https://github.com/Rudd-O/run-in-gui Pull requests to, well, there. Flames to my personal email. I'm sure it's buggy as fuck since it's been working only for the last half an hour or so, but we pulled it off together in the space of 2 hours. Enjoy! Doesn't Amarok starts if you prefix it with the right DISPLAY variable? Like »DISPLAY=:0 amarok«. This should work from cron, too. Regards ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Small tool to spawn programs in graphical sessions from non-graphical ones
Based on systemd's related sibling loginctl, I managed to accomplish the holy grail of the 90's: get Amarok to play music on my desktop sessiom from a crontab (motivated by the missus' desire to have an alarm in the home theater that requires her to walk downstairs, to adapt to her polyphasic sleep): https://github.com/Rudd-O/run-in-gui Pull requests to, well, there. Flames to my personal email. I'm sure it's buggy as fuck since it's been working only for the last half an hour or so, but we pulled it off together in the space of 2 hours. Enjoy! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
I would like to be able to run systemd on systems that did not boot up with systemd. For testing purposes and because I have some projects that reuse systemd as a transaction computation engine. Thanks. Colin Guthrie wrote: >'Twas brillig, and Lennart Poettering at 16/10/12 01:18 did gyre and >gimble: >> On Sat, 06.10.12 01:11, Thomas Bächler (tho...@archlinux.org) wrote: >> >>> Running as a user instance won't work at all if systemd isn't >running as system >>> manager, so refuse to start in that case. >> >> Applied. Thanks! > >Did you see Auke's side of this thread? Care to comment on it >officially >regarding the general principle? > >Col > > >-- > >Colin Guthrie >gmane(at)colin.guthr.ie >http://colin.guthr.ie/ > >Day Job: > Tribalogic Limited http://www.tribalogic.net/ >Open Source: > Mageia Contributor http://www.mageia.org/ > PulseAudio Hacker http://www.pulseaudio.org/ > Trac Hacker http://trac.edgewall.org/ >___ >systemd-devel mailing list >systemd-devel@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Running a service at shutdown time before file systems are unmounted
I need to run a program right before any file system is unmounted, to record the current file system state on disk. What Requires/RequiredBy, Wants/WantedBy, Before/After dependencies should I encode in my unit file? Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] fstab now parsed by generator in systemd git
> > Inotify? Calls systemd? Parses again? Dome already? In the above > > paragraph almost all wrong. > > Well, I did not check the code. But when the generator creates the > unit in /run, it must be notified somehow to systemd, no? Isn't it > inotify? Nothing gets notified at generator time. Generator time happens during early boot, where systemd suspends its activities, calls all generators, and THEN (re?)parses all unit files to determine the final transaction. During generator time, systemd takes no action, receives no notifications, nothing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question about mount unit generators
As you can tell from my code: https://github.com/Rudd-O/zfs/blob/master/systemd/systemd-zfs-generator.in I carefully calculate dependencies so the file systems are mounted in the correct order. Now that fstab unit generation is moving to a generator, I read the code in systemd.git. I discovered it does not calculate dependencies (what file systems to mount first) at all. It just sets very simple befores= and afters=. However, the proper dependencies DO show when I do systemctl show (resp. mount unit). Thus my question: Would it be correct to say that the generator I wrote absolutely does not need to calculate parent file system dependencies, because some black magic inside systemd / systemctl knows to figure out the parent file system dependencies thus guarantees mounting in the right order?? Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] mount: Add a new remote-fs* target to specifically delay logins until home dirs are available
Thank you very much for fixing my pet peeve.
Do you have a Bitcoin address where I can tip you?
On Mon, 2012-04-02 at 11:31 +0100, Colin Guthrie wrote:
> Previously, systemd-user-sessions.service started after remote-fs.target.
> If the user had any NFS mounts defined, this prevented logins until these
> were processed.
>
> If the user was using NFS for their home directories, this configuration
> makes sense, but equally, the user may have remote mounts defined that
> are non-critical for logins and thus shouldn't delay login availability.
>
> Even using the "nofail" mount option does not help as
> systemd-user-sessions.service will still wait for remote-fs.target which
> although it does not require units, it does still have to run, thus it
> will wait for remote-fs-pre.target which in turn will wait for the
> network to be ready. All these things will delay the startup.
>
> Therefore, rather than start after remote-fs.target directly, instead
> provide an more granular remote-fs-login.target that will only have
> dependances of fstab entries not marked with nofail.
>
> Thus if an NFS mount is not critical for logins, it should be marked
> with nofail mount option and it will not delay the login availability.
> ---
> Makefile.am|1 +
> man/systemd.special.xml| 19 +
> src/mount.c| 36
> ++--
> src/special.h |1 +
> units/remote-fs-login.target |9
> units/systemd-user-sessions.service.in |2 +-
> 6 files changed, 61 insertions(+), 7 deletions(-)
> create mode 100644 units/remote-fs-login.target
>
> diff --git a/Makefile.am b/Makefile.am
> index 2f6794a..fb81e81 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -271,6 +271,7 @@ dist_systemunit_DATA = \
> units/local-fs.target \
> units/local-fs-pre.target \
> units/remote-fs.target \
> + units/remote-fs-login.target \
> units/remote-fs-pre.target \
> units/network.target \
> units/nss-lookup.target \
> diff --git a/man/systemd.special.xml b/man/systemd.special.xml
> index 116a43c..73dbc1d 100644
> --- a/man/systemd.special.xml
> +++ b/man/systemd.special.xml
> @@ -68,6 +68,7 @@
> reboot.target,
> remote-fs.target,
> remote-fs-pre.target,
> +remote-fs-login.target,
> rescue.target,
> rpcbind.target,
> runlevel2.target,
> @@ -400,6 +401,24 @@
>
>
>
> +
> remote-fs-login.target
> +
> +Similar to
> +
> remote-fs.target,
> +but only for remote mount points
> marked
> +without nofail.
> +Remote mounts with nofail are
> +considered to be non-critical to
> +the login process. If any such mount
> +points exist, remote-fs.target will
> +automatically require in this target.
> +systemd-user-sessions.service is
> ordered
> +after this target, thus ensuring
> logins
> +are only available when all
> (required)
> +remote mounts are ready.
> +
> +
> +
>
> rescue.target
>
> A special target unit
> diff --git a/src/mount.c b/src/mount.c
> index ed0f819..8b3b130 100644
> --- a/src/mount.c
> +++ b/src/mount.c
> @@ -320,9 +320,9 @@ static bool needs_quota(MountParameters *p) {
> }
>
> static int mount_add_fstab_links(Mount *m) {
> -const char *target, *after, *tu_wants = NULL;
> +const char *target, *after, *tu_wants = NULL, *login_target = NULL;
> MountParameters *p;
> -Unit *tu;
> +Unit *tu, *ltu = NULL;
> int r;
> bool noauto, nofail, handle, automount;
>
> @@ -351,6 +351,7 @@ static int mount_add_fstab_links(Mount *m) {
> if (mount_is_network(p)) {
> target = SPECIAL_REMOTE_FS_TARGET;
> after = tu_wants = SPECIAL_REMOTE_FS_PRE_TARGET;
> +login_target = SPECIAL_REMOTE_FS_LOGIN_TARGET;
> } else {
> target = SPECIAL_LOCAL_FS_TARGET;
> after = SPECIAL_LOCAL_FS_PRE_TARGET;
> @@ -372,6 +373,19 @@ static int mount_add_fstab_
Re: [systemd-devel] systemd prevents pulseaudio from shutting down
You may be a candidate for running pulseaudio as a system service. That is how I solved the problem of sharing audio devices on my headless NAS connected to my studio monitors. On Sun, 2012-06-03 at 18:54 +0200, Reindl Harald wrote: > > Am 03.06.2012 18:46, schrieb Paul Menzel: > >> i'm using "ecryptfs" to encrypt my home directory and "pam_mount" to > >> have it automatically > >> mounted/unmounted at login/logout. The unmounting never worked and i > >> discoverd that a pulseaudio process of my user was keept running > >> although my user was already logged out. This process had some files > >> opened in "~./pulse" which is why i think my home dir is not unmounted. > > > > I will not be able to help you, but you can give more information. What > > distribution do you use? What version of Linux, PulseAudio, systemd? > > Maybe even attach the PulseAudio’s unit file for reference. > > pulseaudio process is not stopped on Fdora 15/16 as example after logout > > i generally hate the idea of sound.daemon depeding on user-sessions > because it prevents things like mpd from running completly in > background and if i hear music on my desktop and switch with CTRL+F2 > to a terminal it is simply idiotic that music stops to play > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: avoid mangling mount source and dest
It will also break ZFS legacy mounts. On Mon, 2012-06-04 at 08:04 -0400, Dave Reisner wrote: > On Mon, Jun 04, 2012 at 12:57:47PM +0200, Kay Sievers wrote: > > On Sun, Jun 3, 2012 at 4:18 AM, Dave Reisner wrote: > > > This can invalidate otherwise valid source paths with trailing slashes, > > > such as "host:/" in the case of a network mount. We don't really have > > > any business touching these anyway, since we'll just pass this to > > > /bin/mount, which sanitizes the paths for us. > > > > Changed it to use: > > path_is_absolute() > > instead of: > > is_path(), > > so that we still sanitize the input we might match against. > > > > Let me know, if you think that could still cause any problems? > > > > Thanks, > > Kay > > Yes, this will still break CIFS shares. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Integrating better with systemd
For a while now, I've been experiencing a few woes related to systemd, booting with ZFS on the root, underlied by dm-crypt, and my generator-based approach. Here is the ideal situation I would like to have: During initramfs: - decrypt all available initial volumes (done by Fedora) - import ZFS pools (done by our scripts) - mount root file system (done by our scripts) During early boot: - discover all file systems mountable and schedule them for mount (done in my branch) - perform late block storage initialization and decryption (done by Fedora) - import any newly available ZFS pools (not done) - schedule any new file systems available for mount (not done) During shut down: - unmount everything (systemd does it) - export pools cleanly (not done) because, if they are imported, the crypt FSes are never closed The "not done" parts are really ticking me off. It is supposedly possible that we can accomplish most of this stuff simply by using udev rules. Udev rules could possibly announce "hey, I found a ZFS array component", and communicate to a userspace program that says "OK, this array is now ready to be assembled and imported, and it really belongs to this system, so import it now". Or "hey I found a bunch of ZFS file systems after importing this array, and these file systems have a policy of mounting on import, so mount them in the right order now". Of course, the question of "which file systems are essential for the system to boot up" is MUCH TRICKIER that way, because ZFS does not specify them on /etc/fstab. So it might be worthwhile to keep my generator-based approach at least for early boot, and use the udev-based approach for pools that are made available later on during or after boot. This would also give us hotplug and automount for free. Can anyone give me more input and ideas? I'd appreciate it a lot. I'm crossposting to systemd-devel because I really have no idea, and this part is really not well documented. Is anyone even using my branch of ZFS with systemd support? -- Manuel Amador (Rudd-O) http://rudd-o.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] small implementation of systemd escaping
Feel free to add to systemd under whatever license you choose. I use it for
my generators in ZFS.
---systemdescaper.c-
#include
int main ( int argc, char ** argv) {
if (argc != 3) {
fprintf(stderr,"usage: --escape \n");
return 0;
}
const char * parm = argv[2];
char character;
int counter;
counter = 0;
character = parm[counter];
while (character != '\0') {
if (character == '/' && counter == 0) printf("");
else if (character == '/' && counter != 0) printf("-");
else if (character <= 32 || character == '-')
printf("\\x%x",character);
else printf("%c",character);
counter++;
character = parm[counter];
}
return 0;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What unit file should I depend on?
I have a question: I need to initialize and mount ZFS pool that is backed by storage devices that are not initialized during very early boot (encrypted LUKS, LVM pools not needed for boot, DMRAID devices). This ZFS process after storage initialization will happen in a service unit. Question is: what unit file should I set in the After= field for my unit? Also, how do I make a unit file active all the time, without having to do systemctl enable XXX.unit? Thanks in advance.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] openvpn@.service
It's a multi-instance service. You can instance it several times based on a parameter, much like tty@.service can be instantiated to be tty@tty1.service. On Tue, 2011-11-15 at 10:06 -0500, Michael D. Berger wrote: > Why does "openvpn@.service" have the '@'? > > Thanks, > Mike. > > -- > Michael D. Berger > m.d.ber...@ieee.org > http://www.rosemike.net/ > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] can not systemctl enable rc.local in final fc16
Rc DASH local. Service. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. floydsm...@aol.com wrote: I can not systemctl enable rc.local.service in final fc16 - error is: Failed to issue method call: No such file or directory I have insured I have files: [root@floydsmi ~]# ls -lZ /etc/rc.local /etc/rc.d/rc.local root root system_u:object_r:etc_t:s0 /etc/rc.d/rc.local -rwxr-xr-x. root root system_u:object_r:etc_t:s0 /etc/rc.d/rc.local lrwxrwxrwx. root root system_u:object_r:etc_t:s0 /etc/rc.local -> ../etc/rc.d/rc.local What do I need to do in my kickstart file to ensure that this service is started on boot? Any help will be greatly appreciated. Floyd, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requires and After
Both. Otherwise your daemon can be started in parallel and be done before the other daemon. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. "Michael D. Berger" wrote: myDaemon must start after myBaseDaemon, and must start only if myBaseDaemon is started. Do I use: After=myBaseDaemon Requires=myBaseDaemon ;or only: Requires=myBaseDaemon ? Thanks, Mike. -- Michael D. Berger m.d.ber...@ieee.org http://www.rosemike.net/ _ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: Re: Question about generators and adding new units in the middle of a transaction
-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. "Manuel Amador (Rudd-O)" wrote: I want systemd to mount file systems in parallel. That is all. ZFS does not use fstab for the purpose, it has its own zfs mount -a command. ZFS mount -a will fail when: / zfs /home ext4 /home/rudd-o zfs As it will attempt to mount /home/rudd-o without /home mounted. It will also not mount fs'es in parallel. Systemd has none of those problems. Without systemd mointing ZFS file systems, also, there is no way to mount zfs file systems early. Wich means no /var or /usr on zfs.! Mounting zfs filesystems through systemd fixes that. So how do i tell systemd that we have just discovered a new filesystem to be mounted then? Hotplug hook? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Kay Sievers wrote: On Fri, Nov 4, 2011 at 13:22, Manuel Amador wrote: > I am developing systemd support for ZFS: > as you can see, I create the units early on bootup using a generator (a > mechanism that is entirely undocumented, tsk). It isn't documented, because it's use is not encouraged for most use cases. The main focus is to be able to support compatibility wrappers for sysv init scripts, fstab, cryptab, means: read a legacy file and create a systemd unit from it. It is not a hotplug hook. > Now, this will happen during udev settle. What I want is to generate more > units when pools are discovered and their file systems require to be mounted > automatically. That is, I need to re-run the generator and generate new > units, and then tell systemd to daemon-reload. The generator runs _before_ systemd starts, if you need to reload systemd's config during bootup, generators are absolutely not what you are looking for. I did not look at the details, maybe you want an instantiated foo@.service? I fear, that you are trying to force the systemd service engine into a storage management daemon, which is not what we want. If instantiated services don't help, a more general/higher level description of the problem might be helpful for us to understand the problem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
