Re: [arch-general] Optimizing boot
On April 30, 2014 1:28:52 PM GMT+03:00, Paul Gideon Dann pdgid...@gmail.com wrote: On Wednesday 30 Apr 2014 11:08:14 Mike Cloaked wrote: Just a comment about boot times. The overall boot performance will depend not only on optimising an individual setup, but also is dependent on the hardware as well as which boot manager is being used. So an older laptop with a hard drive, using BIOS boot and optimised will still see much longer boot time than say a new laptop running a fast i7 processor, with an ssd, using UEFI and also optimised. Certainly I have an old laptop that takes around 35 seconds to boot to the login prompt from when the boot manager takes over after POST using BIOS legacy boot, but a similarly set up and optimised new Haswell i7 laptop, with msata ssd using refind for UEFI boot takes about 7 seconds to reach the KDM login prompt. Of course for a specific system it may be possible to shave some seconds off the boot time, but it will also depend on which server daemons need to be started as well. So adding dovecot, an MTA, and maybe a DHCP server all add to the time taken to complete the boot process. So comparisons of absolute boot times from different machines are difficult to interpret. Since we're on the topic, does anyone have a clue how I can find out why systemd hangs for ages when I shut down or reboot? The display server is shut down, I'm placed in a TTY with a shutting-down message, but then it looks like it's waiting for something that never happens, and then I think I see something flash past about a watchdog timeout before it proceeds. If I could get rid of that hanging step, it would save me waiting 60 seconds or however long each time I reboot (which is infrequently enough that it's only been a mild annoyance so far). What's the correct way to diagnose this? I don't think systemd-analyze can handle shutdown. Could this be an initrd thing? Paul I see the same thing on my box. The system shuts down, I get a message to that effect printed, yet the hardware keeps running for more than 3m. Eventually, I always cold-shutdown the computer when it reaches that state. Any ideas why this is? Gesh
Re: [arch-general] Configuring enabled services
On March 27, 2014 9:25:24 AM GMT+02:00, Thomas Bächler tho...@archlinux.org wrote: Am 26.03.2014 23:13, schrieb Gesh: Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. What this means for backing up the configuration is that you simply back up /etc/systemd/system without resolving symlinks (and ignore that those symlinks point to paths outside of your backup). rsync can do that for you. This has the benefit of also backing up all permanent unit overrides and drop-ins that the admin may have made. Basically, if I understood what happens correctly, the units under /etc/systemd/system/*.wants/ - or their targets, if they're symlinks - replace their corresponding units in the dependency graph. In addition, all unit files are installed to /usr/lib/systemd/system/, and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Is this understanding correct? Thank you for your time, Gesh
Re: [arch-general] Configuring enabled services
On March 27, 2014 11:20:04 AM GMT+02:00, Thomas Bächler tho...@archlinux.org wrote: Am 27.03.2014 09:41, schrieb Gesh: Basically, if I understood what happens correctly, the units under /etc/systemd/system/*.wants/ - or their targets, if they're symlinks - replace their corresponding units in the dependency graph. Not exactly. When you place a unit in foo.wants, then foo gets an additional Wants= dependency. Basically, this is a way to extend units with new Wants= and Requires= statements without modifying unit files. You don't *replace* the dependency graph, but *extend* it. But what if bar.unit Wants=foo.unit and I add a custom foo.unit to bar.unit.wants/ ? Will both be run? Will the custom foo.unit replace the built-in? In addition, all unit files are installed to /usr/lib/systemd/system/, Unit files can also be installed to /etc/systemd/system/, for example if you want to use a modified version of a system-supplied unit file. I meant in the sense of convention. Of course a sysadmin can drop units into /etc. It's its entire raison d'être. When you run start or enable on a unit name, system looks into those directories, taking the first one it finds. /run/systemd/generator.early /etc/systemd/system /run/systemd/system (*) /run/systemd/generator (*) /usr/lib/systemd/system /run/systemd/generator.late I am not 100% sure if I got the order of the ones marked with (*) right. As you can see here, there are units installed by the package manager (/usr/lib), units installed by the admin (/etc), temporary units installed either by automatic tools or by the admin (/run/systemd/system) and units installed by generators during systemd startup or reload (/run/systemd/generator*). Again, backing up the ones in /usr/lib does not make sense since those are contained in packages and can be reinstalled. Backing up the ones in /run makes no sense either since they only live until you reboot (or reload the configuration, in the case of generator units). However, backing up /etc/systemd/system entirely (not just the symlinks) make lots of sense, since the admin is likely to have custom units in there. and the symlinks must have the same name as their targets, so only the symlinks' names need to be backed up. Not necessarily. For example, /etc/systemd/system/display-manager.service points to /usr/lib/systemd/system/kdm.service. Most symlinks have the same name, but that's only convention, not necesity. Therefore, only what's under /etc/systemd/system/ needs to be backed up, ignoring symlinks' targets. I'd back up the symlinks including their targets. This makes it easier to restore configuration. So basically, you back up the directory under /etc not following symlinks, then when restoring use pkgfile, filenames and installed-package-list to determine what packages you need to reinstall to get those links working. Besides that, the .wants directories in /usr/lib/systemd/system/ are managed by pacman, and represent upstream decisions to automatically start their units. Indeed. OK. I assume the links under /etc are generated by systemctl when enabling a unit with an [Install] section? Thanks for the clarifications, Gesh
Re: [arch-general] Configuring enabled services
On March 19, 2014 9:16:57 PM GMT+02:00, Ary Kleinerman akleiner...@buinet.com.ar wrote: There's not really much magic going on. Are you aware of: /etc/systemd/system This contains symlinks that do already pretty much what you describe, and this is systemd's native configuration. Paul, Don't forget /run/systemd/system: Runtime units and /usr/lib/systemd/system: Units of installed packages Regards, Ary Thanks for the pointers. If I understand what's going on correctly, units specify in their [Install] section whether, when they're enabled, they should be pulled in by other units. Those symlinks usually populate the appropriate directory under /etc/systemd/system/. Besides that, some packages install symlinks under /usr/lib/systemd/system/ as part of their files to get pulled in by other units without requiring user intervention. Finally, systemctl list-unit-files will list all unit files with their enabled/disabled/static status, where static means that they run by default (when pulled in) and disabled means they can be installed - that is, they have an [Install] section - but haven't been yet. And systemctl enable/disable manages the symlinks under /etc/systems/system specified by the [Install] section. Is my understanding of the situation correct? Thanks, Gesh
[arch-general] Configuring enabled services
Dear all, I've been rereading the old arguments on the rc.conf split. Disregarding everything discussed there, one interesting point came up during that discussion.[1] Is it possible to have some configuration file, e.g. /etc/systems/services.conf that would list all the units one wants to be enabled at boot? This would both simplify backups and reduce the magic of and dependence on systemctl. Is there any reason this can't or shouldn't be done? With best regards, Gesh [1] - http://permalink.gmane.org/gmane.linux.arch.general/43459
Re: [arch-general] Any way to change .PKGINFO post build w/o Rebuilding?
On February 26, 2014 10:52:43 AM GMT+02:00, Karol Blazewicz karol.blazew...@gmail.com wrote: On Wed, Feb 26, 2014 at 9:35 AM, Emil Lundberg lundberg.e...@gmail.com wrote: I don't mean to be rude, but have you tried it? Pacman packages are tar.gz archives, so my guess is it's possible /Emil. On Wed, Feb 26, 2014 at 4:13 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: All, I patched tdebase for the logind-multiseat patch as was applied to kde-workspace for Arch kde4. Doing so, I forgot to change the provides= replaces= information. Now the new package will not install due to every file conflicting with an existing file. The new file is named 'tde-tdebase-systemd' and it replaces a package named 'tde-tdebase'. Can I decompress the package and manually edit the .PKGINFO file and then recompress the file and have it work? The package is unsigned if that makes any difference. What is currently in the .PKGINFO file is: # Generated by makepkg 4.1.2 # using fakeroot version 1.20 # Wed Feb 26 06:24:01 UTC 2014 pkgname = tde-tdebase-systemd pkgver = R14preRC1-1 pkgdesc = Trinity Desktop Enviroment base components - TDE upstream GIT url = http://scm.trinitydesktop.org/scm/git/tdebase builddate = 1393395841 packager = David C. Rankin drankinatty at gmail dot com size = 78513152 arch = i686 license = GPL replaces = trinity-tdebase snip provides = tdebase provides = tde-tdebase I think the change needed is: replaces = tde-tdebase replaces = trinity-tdebase provides = tdebase provides = tde-tdebase Does this have a chance of working or should I just bite the bullet and rebuild the package? -- David C. Rankin, J.D.,P.E. Try https://bbs.archlinux.org/viewtopic.php?pid=1285524 A naïve reading of [1] suggests that makepkg -R should do the trick. However, as I'm away from my computer, I can't test this. Gesh [1] - https://www.archlinux.org/pacman/makepkg.8.html
Re: [arch-general] Thank you
Many thanks to the Arch Linux community for creating what is, in my opinion at least, the most beautiful, simple and usable distribution in existence. Having had to deal with Debian over the past week, I've continually hungered for the sweet simplicity Arch offers. Thank you for keeping the system clean, for easing the lives of systems administrators everywhere by keeping out of their way, and for teaching newbies how Linux works by leaving its guts visible. May you retroactively have had a happy solstice, Gesh
Re: [arch-general] Package Maintenance Classroom (31/3/2013)
I'm interested in attending. Worst-case scenario, I will only get a refresher. Best-case scenario, I'll discover I'm an idiot and that there are things I'm doing wrong. Should be fun. See you next week, then! Gesh On Sun, Mar 17, 2013 at 4:14 AM, William Giokas 1007...@gmail.com wrote: All, At the end of this month Daniel Wallace (gtmanfred) and I will be giving a classroom on basic package maintenance. From the forum post[1]: And now we have planned our first actual class: A Beginners Guide to Package Maintaining. This will be taught by gtmanfred and myself Sunday, March 31st at 16:00UTC in the #archlinux-classroom channel. There is already an Arch Wiki[2] page about this class listing the requirements and lesson plans. This class will be broken into separate lessons, the first being a simple introduction with guided practice and explanations. We will be covering more advanced topics later on. Even if you are not new to package maintenance, we would like to see you there for support and just in case/when we get things wrong you can correct us. We will also be covering the new functions and uses of pacman 4.1, currently in the rc stage, particularly its use with version control sources and development packages in the later lessons. There will be a pdf file released when the class begins so that you can follow along. We will be releasing an info document too, for those of you that do not use X but still want to follow along. Thank you, and we hope to see you there! If you have any questions about the requirements or prerequisites, then please ask on the IRC channel. We will be glad to clear things up. If you are interested, please reply or post on the forums so we know about how many people we're going to have to help. Thank you, -- William Giokas | KaiSforza GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF [1]: https://bbs.archlinux.org/viewtopic.php?pid=1243733#p1243733 [2]: https://wiki.archlinux.org/index.php/Beginners_Guide_to_Package_Maintaining
Re: [arch-general] SOLVED Re: Cannot chroot '/bin/bash': No such file or directory
Also, this move was publicized in the forums, IRC topic, mailing list and front-page news. Seriously, if you're updating a months-old system, you'd better go over the front-page news, at the very least. Gesh On Fri, Mar 15, 2013 at 11:38 PM, Rodrigo Rivas rodrigorivasco...@gmail.com wrote: On Fri, Mar 15, 2013 at 5:32 PM, David C. Rankin drankina...@suddenlinkmail.com wrote: On 03/12/2013 04:13 PM, David C. Rankin wrote: There needs to be a check in the current update that checks to see whether the /lib link can safely be removed -- before it is removed by whatever package update does it. Otherwise, anyone who has not updated in several months will be hit by the same issue. I don't think this link can be removed at all! It is still in `filesystem`, at least in my filesystem-2013.03-2. And it is needed by practically every program, as the default dynamic linker is set to `/lib/ld-linux.so.2`, at least in i686. Then, there is the question of how did you happen to lose this link... I don't have an answer for that. Rodrigo
