Re: [arch-general] Suspicious activity and slowness ...
On Mon, 17 Dec 2018 at 15:04, Peter Nabbefeld wrote: > > since some days, I'm noticing HD is too busy, and my laptop is very slow > in some cases. > > It might also be worth checking the health of your hard disk with "smartctl -A /dev/sd". Look out for "Reallocated Event Count", "Current Pending Sector", and "Offline Uncorrectable". These should be zero. If they're not zero, the hard disk may be slowing down due to the firmware trying to correct disk read errors transparently, causing processes to spend an excessive time in IO-wait. I've found that these days, failing hard disks tend to cause slow-downs rather than outright crashes. Paul
Re: [arch-general] Can I build Arch Linux from Scratch?
On 8 August 2018 at 02:33, Turritopsis Dohrnii Teo En Ming < turritopsis.dohr...@teo-en-ming.com> wrote: > Good morning from Singapore, > > > Can I build Arch Linux from Scratch like Linux from Scratch? > It's certainly possible to build all of ArchLinux's packages from source using the ABS. My approach would be to start on any Linux distribution by building Pacman, which will provide the makepkg script to allow you to start building Arch packages from source using PKGBUILD files. You'd want to start with the packages in the "base" group, followed by base-devel. You should be able to use Pacman to install each package file into a chroot, at which point your Arch system will be bootstrapped. But that's a lot of work. It's an interesting project, but I'm not sure there's much to be gained, practically, by building Arch like this as opposed to installing the pre-built packages. Paul
Re: [arch-general] Latest openssh - Premier connectivity tool for remote login with the SSH protocol?
On 17 July 2018 at 15:48, David C. Rankin wrote: > It's like there is something between: > > 09:20:24 phoinix systemd[1]: Started Session c18 of user david. > and > 09:20:28 phoinix sshd[2654]: Received disconnect from 66.76.46.195 port > 59956:11: disconnected by user > > that isn't data transfer and isn't rsyc checking if files need updating. > > Also interestingly, the 5 boxes on my lan that are in the backup list do > not > show this type of delay. For example same connection and same box, but on > lang > and not internet. > Personally, I'd be leaning *heavily* into checking that the rsync & data transfer time really hasn't increased. I think it's extremely unlikely that any kind of deliberate delay has been added. It wouldn't be a particularly smart solution to the DDOS problem. Have you run the backup script manually on the remote machine, to check that it still completes in under a second? You could also do some tests such as "ssh remotehost echo hello" to test connection + shell spawn time. Paul
Re: [arch-general] Re-install of Arch on a larger drive
I've moved or cloned my general-use Arch system between disks more times than I can count. This is what LVM is for. If you're not using LVM (or BTRFS), I recommend you start, but in the meantime, the simplest solution when moving between systems is to dd the contents of each partition from the source disk to the destination disk, and then expand filesystems as necessary: sudo dd if=/dev/sdx1 of=/dev/sdy1 bs=1M oflag=direct sudo fsck -f /dev/sdy1 sudo resize2fs /dev/sdy1 Paul On 18 March 2018 at 17:08, Doug Newgard via arch-general < arch-general@archlinux.org> wrote: > On Sun, 18 Mar 2018 17:46:21 +0100 > Ralf Mardorf wrote: > > > On Sun, 18 Mar 2018 11:33:19 -0500, Doug Newgard via arch-general wrote: > > >On Sun, 18 Mar 2018 17:30:27 +0100 Ralf Mardorf wrote: > > >> The "dd" command is inappropriate, a "cp -a" is the most reasonable > > >> solution. However, UUIDs are still an issue, the average desktop > > >> computer user should consider to prefer a lable over an UUID. > > > > > >Why is it inappropriate? It should work fine, and work with no other > > >changes. Even the UUIDs/Labels would be the same that way. > > > > If so, don't beat around the bush, simply provide the command that does > > it all :). > > If you need more than what Ricardo Band already posted, you're beyond help. >
Re: [arch-general] Depends on foo-bar=10.0-3
On 14 August 2017 at 13:48, Ralf Mardorf wrote: > On Mon, 14 Aug 2017 14:03:45 +0200, mpan wrote: > >> why does a package from official repositories mentions what version > >> of a dependency is required? > >Because it may be that it is working only with that particular > >version. > > That doesn't explain why it is needed or in any way useful for a package > provided by official Arch repositories? Partial upgrades are > unsupported [1]. Actually it could be vary annoying, if packages now > start including the version of a dependency. I didn't notice that > packages mention dependency versions for at least the last 4 years [2]. > It's not the only dummy package I'm using for at least that long. > Yes, partial upgrades are unsupported, but in practice this still happens, usually not deliberately. For instance, I will quite often do a "pacman -S " without doing a full system update first, assuming that *probably* nothing important has changed since the last update. It's a sloppy practice, but humans cut corners: it happens. When a plugin relies on a potentially unstable ABI (not many applications offer stable ABIs), specifying that the plugin package requires that exact version of the application will ensure that mistakes like this don't happen. If I see an error like "package x requires y=1.2.3" when installing a package, the first thing I'll try is a system update, an obscure segfault is avoided, and everyone's happy. So the failsafe does the job. It's good defensive practice by the packaging team, I think. Paul
Re: [arch-general] Why there is no NetworkManager in ArchISO
On 24 July 2017 at 08:54, Junayeed Ahnaf via arch-general < arch-general@archlinux.org> wrote: > I've installed ArchLinux on 3 desktops so far, and I've done them > successfully, so I must have *RTFM* , I was just wondering why is it > hard to configure wifi. Since I failed to configure wifi with > wpa_supplicant. I'll try with wifi-menu today, and report progress. > I get where you're coming from: wpa_supplicant is powerful, but is not particularly easy to set up manually, and I always used to groan when I had to rely on Wifi in archiso. But wifi-menu takes all the pain away: it's simple and straight-forward now. Paul
Re: [arch-general] MariaDB not starting
On 27 January 2017 at 12:12, Peter Nabbefeld wrote: > I've got problems with MariaDB not working. > I think you might want to read the "Installation" section on the Wiki: https://wiki.archlinux.org/index.php/MySQL#Installation In particular, I think you forgot to run mysql_install_db. Cheers, Paul
Re: [arch-general] Installation: How to get HDD > LUKS > GPT working in a clean way
On 2 December 2016 at 22:29, Merlin Büge wrote: >> Personally, I'd rather modify the start-up process a tiny bit so that >> GPT inside LUKS gets parsed. I just try to strip off unnecessary >> 'overhead' / layers of my system. > If you have 8 GiB or more and not hibernating, don't bother with swap, > it'd be a waste of disk space. In that case you could just put a btrfs > volume straight on the LUKS container without the GPT. Problem solved as > you don't need any more volume management than opening LUKS containers. If another opinion helps, I've done some funky disk layouts at various times, and I also think that if you need partitioning above the LUKS layer, you'd do better to use LVM than GPT. GPT is intended to be used at the lowest level of the stack, whereas LVM is well-supported at pretty much any level. If you do go ahead with it, double-check that you won't get block alignment issues in that stack that could affect IO performance. However, if you say that you don't need the flexibility of LVM, I'd certainly first try btrfs directly on top of LUKS. Final consideration: if you want GRUB to open a LUKS container and then load stage 2 from btrfs, you'll need a decent amount of storage for the GRUB 1st stage, which on a traditional setup goes in free space you need to account for after the MBR (or on the EFI partition for UEFI setups). In your case, as the whole disk is LUKS and you have no partition table, have you considered where the GRUB 1st stage will be stored? I use a USB stick to boot GRUB stage 1 on my encrypted machines, and that may work for you too. Paul
Re: [arch-general] Alternative init system proposal
On 23 February 2016 at 08:32, Frank Schaffhaeuser wrote: > This topic again? Seriously? The last 'discussion' from Feb.8th thankfully > just died down > and apart from spamming subscriber's inboxes had no useful effect... > Please, not again Hang on, I absolutely agree with you that I'm sick of the "alternative init system" argument, but Eric here is saying something quite positive: Arch is a system that gives its users the freedom to do whatever they want with their system. His point is that we should not be bothering the devs with this stuff: he is proof that we as users have everything we need to make our system work however we want it to, and for that we can be grateful. Good for you, Eric. It's great to see someone scratching their own itch in true Open Source style :) Paul
Re: [arch-general] How much people use Arch Linux
The nature of ArchLinux as a rolling-release distro means that ISO downloads are not a good measure of the number of users at all. (Most users downloaded an ISO once, a long time ago, and not for each release as for other distros.) Add to that the fact that there are torrent links for the ISO as well, for which download counts are probably not available. I think the only way to get some kind of measure would probably be to aggregate a count of IPs hitting each of the Arch package mirrors, which would be a colossal undertaking :D Paul On 18 February 2016 at 21:12, Sebastiaan Lokhorst < sebastiaanlokho...@gmail.com> wrote: > 2016-02-18 21:42 GMT+01:00 Tim Ohliger : > > > I do not know about a download counter, but maybe distrowatch.com is > what > > you are looking for. > > > > DistroWatch itself says: > >The DistroWatch Page Hit Ranking statistics (...) correlate neither to > usage nor to quality and should not be used to measure the market share of > distributions. > > So that's not a good measure. > > The only statistics I know about are at [1], but those are opt-in. So > probably not a good measure either. > > Regards, > Sebastiaan > > [1] https://www.archlinux.de/?page=Statistics >
Re: [arch-general] Plasma 5
On 16 February 2015 at 18:14, Kevin Ott wrote: > > 1) I'm using SDDM now, but even with KDE4, I was unable to get SDDM to > > actually launch a Plasma session. After entering my details, I get a > black > > screen and no further activity. I have to switch to another console, log > > in, and invoke startx myself. > > I had this problem too for a while. It turned out that I had zsh > misconfigured > in some way. I cleared out all my zsh configuration files to start fresh > and > sddm worked. I still don't know exactly what caused it and it certainly > may be > an upstream bug, but that solved it for me. > Thanks; you got me on the right track looking into ZSH. I found the fix here: https://github.com/sddm/sddm/pull/358/files This applies to /usr/share/sddm/scripts/Xsession, and I guess it'll be rolled into the next sddm release. Paul
Re: [arch-general] Plasma 5
On 16 February 2015 at 13:23, Antonio Rojas wrote: > > 2) I used to have some global shortcuts for launching certain apps. I > > don't seem able to set these up any more. After setting a shortcut on a > > lancher in the panel (e.g. Firefox), nothing happens when I actually hit > > the shortcut combination. > > Confirmed, please report upstream I managed to fix the global shortcut issue through "Custom Shortcuts" in the System Settings. I had to create a new global shortcut command, and that seemed to work fine. I had thought that once a shortcut to an application was added to a panel, setting "Shortcut" on that widget would invoke the application, but that's not the case. The shortcut in the widget configuration panel seems to be a generic setting, which I assume is intended to e.g. open widget panels and other UI-type interactions, such as a folder view. However, global shortcuts are ignoring my keyboard layout. That's a frustrating issue. I'll report that upstream if it's not already reported. Paul
[arch-general] Plasma 5
After switching to Plasma 5 from KDE SC 4, I have a couple of small issue, and I wonder if anyone else already has a solution? 1) I'm using SDDM now, but even with KDE4, I was unable to get SDDM to actually launch a Plasma session. After entering my details, I get a black screen and no further activity. I have to switch to another console, log in, and invoke startx myself. 2) I used to have some global shortcuts for launching certain apps. I don't seem able to set these up any more. After setting a shortcut on a lancher in the panel (e.g. Firefox), nothing happens when I actually hit the shortcut combination. 3) Despite installing sni-qt, I'm getting no tray icon for my Telepathy IM contacts. 4) I'm not sure how to get my beloved comic widget back on my desktop :( Paul
Re: [arch-general] keymap corruption
On 11 January 2015 at 22:44, Michael Dahlberg wrote: > On January 11, 2015 at 5:36:35 PM, Oliver Temlin (tem...@gmail.com) wrote: > On 11 January 2015 at 21:38, Michael Dahlberg wrote: > > I recently had a hard drive failure which resulted in my system having a > corrupted /var. I removed /var and recreated it from backups, however now i > seem to have a unique problem: when I log into the console the backspace > and ESC keys do not function correctly. Both keys just result in advancing > the cursor. Strangely, if I boot into the rescue.target, the keys work > correctly. > > > > Any suggestions will be greatly appreciated. > Have you tried reinstalling kbd? Maybe the keyboard definitions themselves got corrupted somehow? And maybe check your locale (including locale-gen) and console font? Paul
Re: [arch-general] Please help, after i686 install screen is unreadable blocky white squares.
On 9 December 2014 at 23:00, John Doe wrote: > Please help, after i686 install screen is unreadable blocky white squares. > > How did you perform the install? Did you follow the guide at https://wiki.archlinux.org/index.php/Beginners_Guide ? If so, it would be a good idea to read back through each of the steps to make sure you didn't forget anything. The first thing I would check is that you did everything that was required for console fonts and locale (e.g. running locale-gen after modifying /etc/locale.conf). Hope this helps, Paul
Re: [arch-general] kernel compilation with ABS
On 7 November 2014 12:01, arnaud gaboury wrote: > > > > Did you try deleting the file and start downloading again? > > Not sure what you call "the file", but I already tried many times to > remove core/linux then run again $ ABSROOT=. abs core/linux. > > I can manually download the kernel and pacth from > https://www.kernel.org/pub/linux/kernel, but now hen using $ makepkg > > > > > -- > > google.com/+arnaudgabourygabx > I've always used yaourt, which may be no good for you, but in the interests of offering another idea: # yaourt -G linux # cd linux # makepkg If the same thing happens, that's new information, at least! Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 16:24, Mateus Rodrigues Costa wrote: > Em Mon Nov 03 2014 at 14:08:11, Paul Gideon Dann > escreveu: > > > > I'd forgotten about this, although I mentioned it a few posts back: > > > > # locale > > locale: Cannot set LC_CTYPE to default locale: No such file or directory > > locale: Cannot set LC_MESSAGES to default locale: No such file or > directory > > locale: Cannot set LC_ALL to default locale: No such file or directory > > LANG=en-GB.utf8 > > LC_CTYPE="en-GB.utf8" > > LC_NUMERIC="en-GB.utf8" > > LC_TIME="en-GB.utf8" > > LC_COLLATE="en-GB.utf8" > > LC_MONETARY="en-GB.utf8" > > LC_MESSAGES="en-GB.utf8" > > LC_PAPER="en-GB.utf8" > > LC_NAME="en-GB.utf8" > > LC_ADDRESS="en-GB.utf8" > > LC_TELEPHONE="en-GB.utf8" > > LC_MEASUREMENT="en-GB.utf8" > > LC_IDENTIFICATION="en-GB.utf8" > > LC_ALL= > > > > Looks like there are still locale issues... > > > > Paul > > > > Looks like it wants some unavailable locales. Is the en_US.utf8 locale > available? Also shouldn't it be "en_GB" instead of "en-GB"? > Yes! Right on the money. I don't know when locale became more fussy, but fixing that dash to an underscore fixes the issue with locale: # locale LANG=en_GB.utf8 LC_CTYPE="en_GB.utf8" LC_NUMERIC="en_GB.utf8" LC_TIME="en_GB.utf8" LC_COLLATE="en_GB.utf8" LC_MONETARY="en_GB.utf8" LC_MESSAGES="en_GB.utf8" LC_PAPER="en_GB.utf8" LC_NAME="en_GB.utf8" LC_ADDRESS="en_GB.utf8" LC_TELEPHONE="en_GB.utf8" LC_MEASUREMENT="en_GB.utf8" LC_IDENTIFICATION="en_GB.utf8" LC_ALL= ...and after restarting my X session, the rendering issues have gone away. *Thanks* everyone involved. I guess the system had been tolerating that incorrect LANG setting in /etc/locale.conf for some time, and an update finally triggered the issue. I definitely didn't touch the file, so I guess some code somewhere decided to be less tolerant. Ultimately my own fault, of course! I'm pretty embarrassed that I hadn't checked it carefully enough! Thanks again to all! Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 15:44, Mauro Santos wrote: > On 03-11-2014 15:26, Paul Gideon Dann wrote: > > So that explains why my locale wasn't being set correctly. However, it > > doesn't explain why I'm seeing broken rendering of special characters in > > the terminal (mainly lines and other terminal graphics). This looks like > it > > might not be directly related? > > > > Paul > > > > If it is terminal emulator under X I would check the font configuration, > if you mean VT then /etc/vconsole.conf is the place to look at. > > On the other hand, I would check what was updated around the time things > started looking weird, maybe you caught a bug, or font handling changed. > > I would also check other terminal emulators, preferably with different > dependencies to try a rule out any bug in the dependencies. > > -- > Mauro Santos > I'd forgotten about this, although I mentioned it a few posts back: # locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL= Looks like there are still locale issues... Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 15:05, Mauro Santos wrote: > On 03-11-2014 14:03, Paul Gideon Dann wrote: > > My best bet at this stage is that I have a corrupted file somewhere, but > > pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue > > with a new package version, but as I'm the only one seeing this, I assume > > it must be a configuration / corruption issue with my specific system. > > > > Paul > > > > Did you check /etc/profile.d for any changed/added files that may be > changing the locale? > > -- > Mauro Santos > Thanks to all for the suggestions so far. This in particular did yield something interesting: The /etc/profile.d/locale.sh file (from the "filesystem" package) changed recently. Basically, it looks like the logic has altered a little: whereas previously it would unset LANG and source /etc/locale.conf, it now only sets LANG if it's not already set. That explains the weird interaction with my zshenv: it was supposed to fall back to en_US in zshenv, but in fact was always setting en_US, which was later forcibly reset to en_GB by /etc/profile.d/locale.sh. After the filesystem update, /etc/profile.d/locale.sh was leaving LANG as it was. I've fixed this in my .zshenv for now. So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like it might not be directly related? Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 11:36, Mateus Rodrigues Costa wrote: > Shouldn't you also have the en_US locales available? Just in case? > Also, why enable the ISO locales if you can run basically with only the > UTF-8 ones? > I've tried enabling the en_US locales, and it doesn't help. I suspect the issues I'm having with console rendering is actually not directly related to the locale, as I've been able to get en_GB.UTF-8 to show up in LANG now by disabling the logic in my ZSH profile that was setting the locale because it was unset. I've no idea how it's set to en_GB.UTF-8 *after* the ZSH config runs, but that seems to be the case. I've tried disabling the ISO locale and re-running locale-gen, but that doesn't help. My best bet at this stage is that I have a corrupted file somewhere, but pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue with a new package version, but as I'm the only one seeing this, I assume it must be a configuration / corruption issue with my specific system. Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 13:37, AIS Information wrote: > > i think you may just have a typo. shouldn't it be "en_GB.UTF-8" instead > of "en_GB.utf8"? > Thanks; I've tried various combinations. Mostly, I've used en_GB.UTF-8, as that matches the entry in locale.conf, and worked fine previously. Your original message was sent in reply to a message digest. I'm replying in the actual thread in the interests of keeping the threads connected. Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 11:03, Jürgen Werner wrote: > Am 03.11.2014 11:03, schrieb Paul Gideon Dann: > > On 3 November 2014 09:45, Jürgen Werner wrote: >> >> You have to run >>> >>> # locale-gen >>> >>> Jürgen, note my original post: >> >> I've checked locale.gen and rerun locale-gen without any effect. I've >>> >> also tried rerunning mkinitpio for good measure. >> >> Paul >> > > Well, I meant after running > > sudo localectl set-locale LANG=en_GB.utf8 > > You didn't list that, so I thought you forgot it. > OK, I see. I can't see why that would be necessary, but in the interest of completeness I've re-run locale-gen, and I'm afraid there was no effect. Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 10:00, Paul Gideon Dann wrote: > > Any more ideas? > Oh BTW, I've also tried bypassing my ZSH config entirely, but no difference. Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 09:45, Jürgen Werner wrote: > You have to run > > # locale-gen > Jürgen, note my original post: > I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure. Paul
Re: [arch-general] Where's my locale gone?
On 3 November 2014 09:24, Jesse Jaara wrote: > Maybe you have the lang set somewhere in your shell configfile. Have you > tried with a new user? > Hmm; yeah, getting somewhere now. I haven't made any modifications to my shell config for a while, but I did find this (I use zprezto): if [[ -z "LANG" ]]; then export LANG='en_US.UTF-8' fi I've commented that out, and I get en_GB.UTF-8 now (which is odd in itself), but Tmux and Vim still render incorrectly: dividing lines are accented characters. The Linux built-in console renders some lines correctly, but some angled lines in Vim are rendered as blocks, so it doesn't seem to be a Konsole thing. When I try to invoke "man", I get: man: can't set the locale; make sure $LC_* and $LANG are correct. I don't have any LC_ variable set manually, but I didn't think I needed to... Also: # locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX en_GB en_GB.iso88591 en_GB.utf8 I've done: # pacman -Qqkk | grep GB ...but that returns nothing. Any more ideas? Paul
Re: [arch-general] Where's my locale gone?
On 31 October 2014 15:42, Mateus Rodrigues Costa wrote: > 2014-10-31 13:34 GMT-02:00 Paul Gideon Dann : > > > > # sudo localectl set-locale en_GB.utf8 > > Failed to issue method call: Invalid Locale data. > > > > Could this be a corrupted file? (Feasible, as we did have a power cut.) I > > tried reinstalling glibc, but that didn't help. > > > > Paul > > > > localectl set-locale LANG=en_GB.utf8 > # sudo localectl set-locale LANG=en_GB.utf8 # echo $LANG en_US.UTF-8 # sudo localectl System Locale: LANG=en-GB.utf8 VC Keymap: dvorak X11 Layout: n/a I tried a new login session too in a fresh VT, and the LANG environment variable is still en_US.UTF-8. Paul
Re: [arch-general] Where's my locale gone?
On 31 October 2014 14:20, Mateus Rodrigues Costa wrote: > 2014-10-31 12:14 GMT-02:00 Paul Gideon Dann : > > > Is there some additional configuration I need beyond /etc/locale.conf > now? > > I've checked locale.gen and rerun locale-gen without any effect. I've > also > > tried rerunning mkinitpio for good measure. > > > > Any ideas? > > > > Paul > > > > localectl list-locales > localectl set-locale en_GB.utf8 Hmm well that helped a little: # sudo localectl list-locales en_GB en_GB.iso88591 en_GB.utf8 # sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data. Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help. Paul
[arch-general] Where's my locale gone?
I'm stumped: I've had LANG=en_GB.UTF8 in /etc/locale.conf ever since the switch to systemd, but in the last few days since my previous reboot, something's changed (maybe systemd 216?) and now I find that, even though /etc/locale.conf still contains en_GB, I get: # echo $LANG en_US.UTF8 This is almost certainly related to why I'm getting messed up character encoding in Konsole. In particular, tmux fails to render dividing lines properly, showing accented 'a' characters instead, and similar things happen in Vim. Is there some additional configuration I need beyond /etc/locale.conf now? I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure. Any ideas? Paul
Re: [arch-general] [arch-dev-public] Changes to microcode updates
On 27 October 2014 09:55, Christian Hesse wrote: > Damjan Georgievski on Thu, 2014/10/23 19:40: > > On 12 October 2014 14:28, Thomas Bächler wrote: > > > Intel released a new microcode update that disables an instruction on > > > Haswell CPUs. However, Linux doesn't handle this very well and in > > > combination with our glibc version, this essentially crashes your > system. > > > > > > The solution is to use the "new" early microcode update mechanism that > > > was introduced almost two years ago ([1]). This means we need to build > > > microcode support into the kernel. > Question: how do microcode updates interact with waking the machine from sleep? I've added the microcode update as an initrd, and it updated fine when I rebooted. However, having since suspended and woken my machine, the kernel log shows a second load of the microcode: [0.00] CPU0 microcode updated early to revision 0x1c, date = 2014-07-03 [0.090603] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [0.111347] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [0.132113] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 [0.334871] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c [0.334881] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c [0.334886] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c [0.334892] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c [0.334931] microcode: Microcode Update Driver: v2.00 < tig...@aivazian.fsnet.co.uk>, Peter Oruba [ 7802.735878] CPU1 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.749970] CPU2 microcode updated early to revision 0x1c, date = 2014-07-03 [ 7802.764074] CPU3 microcode updated early to revision 0x1c, date = 2014-07-03 Note that CPU0 doesn't seem to have been updated. Suspending and resuming again yields a further update to CPUs 1,2,3, but not 0. I'm also getting sporadic failures to launch certain binaries, with an "illegal hardware instruction" error. I'm on kernel 3.17.1-1, which may have something to do with it. I'm aware that 3.17.2 will behave differently with regard to loading microcode. So is this expected behaviour? Any information / ideas / theories? Paul
Re: [arch-general] [arch-dev-public] systemd 216 coming soon to testing
On Thursday 21 Aug 2014 13:40:48 Leonid Isaev wrote: > On Thu, Aug 21, 2014 at 11:56:06AM -0500, Bigby James wrote: > > > > It seems this is just a change in the default settings, nothing more. > > > > > > I know, but not everyone follows systemd-devel. So, just updating > > > systemd would lead to syslog "mysteriously" not logging anything... > > > > Sure, *if* you didn't already explicity set journald to use an external > > logging daemon. If you did, then the update is just going to create a > > *.pacnew file that can be deleted. In other words, the problem is > > improper configuration on the part of the user, not impropriety on the > > part of upstream. > > > > I use syslog-ng myself, and it seems to me that if I'm going to be > > deviating from the defaults set by upstream and the Arch devs then it > > falls to me to pay > Using syslog-ng is not "deviating from the defaults". So far the default was > to send things to _a_ syslog -- no modification of journald.conf was > required (check the old manpages). If I remember correctly, when the switch to systemd was first made, the migration guide on the wiki did in fact talk the user through forwarding the journal to syslog-ng by modifying some config files. Paul
Re: [arch-general] Vim clipboard option
On Thursday 21 Aug 2014 16:24:22 Manolo Martínez wrote: > On 08/21/14 at 11:17am, Magnus Therning wrote: > > On Thu, Aug 21, 2014 at 07:39:50AM +0200, Yamakaky wrote: > > > Hi > > > > > > It's good to have a real vim package, but the `clipboard` option is now > > > disabled (see `vim --version`). Is there any reason ? I use it a lot via > > > the "+ register. > > > > It's disabled in the vim package, but enabled in gvim. Is there any > > particular reason why you want the terminal-only vim to use the X > > clipboard? > > In my case, I prefer the terminal-only vim, yet need to share > information with, say, libreoffice from time to time. So do I, so I use the "vim" command from the gvim package. No problemo! Paul
Re: [arch-general] ImageMagick package missing from repos
On Thursday 31 Jul 2014 09:07:00 Doug Newgard wrote: > > Your database is probably out of date. Try: > > > > # pacman -Syy > > > > and try again. > > > > Paul > > No, do not do -Syy, do -Syu or -Syyu. -Syy just leads to problems. It *just* leads to problems? Mmm; it *may* lead to problems, yes. Experience of what happens in practice tells me that it will almost certainly be fine and will avoid a potentially long and unwanted system update in the middle of work. But yes, technically, it's better to do -Syu so that you're not potentially installing a package that was built against another package that you have have an out-of-date version of, possibly leading to the new package segfaulting or failing to launch. Paul
Re: [arch-general] ImageMagick package missing from repos
On Thursday 31 Jul 2014 18:48:46 Karthik K wrote: > Trying to install ImageMagick from the Arch repos, but I am constantly > getting a 404 not found error > > "pacman -Ss imagemagick" returns > extra/imagemagick 6.8.9.5-1 > An image viewing/manipulation program > > But "pacman -S imagemagick" throws the following error > error: failed retrieving file 'imagemagick-6.8.9.5-1-x86_64.pkg.tar.xz' > from ftp.iitm.ac.in : The requested URL returned error: 404 Not Found > > I tried several mirrors and all are giving the same error Your database is probably out of date. Try: # pacman -Syy and try again. Paul
Re: [arch-general] yaourt - tmpfs error: No space left on device
On Saturday 19 Jul 2014 15:08:51 Alexander Rødseth wrote: > /tmp being too small for building packages after a "standard" Arch > Linux installation, in combination with yaourt using /tmp by default > is a problem. A simple workaround is to run yaourt with --tmp > /somewhere/with/enough/space. When this happens to me, I tend to do: # yaourt -G # cd # makepkg ...in my home directory, which has plenty of storage. Paul
Re: [arch-general] Change installation from 64-bit to 32-bit
On Thursday 10 Jul 2014 19:42:39 Scott Lawrence wrote: > Hey, > > Never tried that particular piece of reckless foolery :). However, I'd guess > that once the libraries were replaced with incompatible versions, the > installation scripts would start to fail, and then you'd be pretty badly > stuck. I also think this would happen. > Instead (but this requires a lot of disk space), perhaps install the 64-bit > versions of all current packages to a chroot, and then do a massive copy? > You'd have to be sure to get the important parts in one command on the copy, > otherwise your binaries might start being unusuable. (Or, install busybox > and use that to do things more carefully.) Yes, I don't think you'll be able to do this in-place. A chroot is a possibility, possibly onto a separate logical volume (if you used LVM?). There's not much difference between doing that and reinstalling from scratch, though. Paul
Re: [arch-general] Change installation from 64-bit to 32-bit
On Thursday 10 Jul 2014 22:10:28 droe6 wrote: > Not even that. You can have functioning 32bit programs running on a 64bit > system. The only reason I can see to change is if you somehow installed a > 64bit system on a 32 bit architecture system. The OP already explained that he wants to make this change because of the increased RAM requirements of 64-bit binaries on a system that has limited resources. Paul
Re: [arch-general] mdmonitor.service failed to start
On Tuesday 24 Jun 2014 10:07:31 Sander Jansen wrote: > > But the new problem is: Why this service automatically start? I never > > manually enabled mdmonitor, and I cannot find its link in > > /etc/systemd/system/ . > > > > Regards. > > It's part of the udev rule in /usr/lib/udev/rules.d/63-md-raid-arrays.rules I was a little puzzled by this too, but what confused me most is why there are two unit files provided by mdadm: mdmonitor.service and mdadm.service. I had the latter enabled previously, but the former is started automatically now. I had to disable mdadm.service, because it now clashes with the automatically-started mdmonitor. No problem, but it did strike me as a little odd. I like that md monitoring happens automatically now, though. That's a good idea. Paul
Re: [arch-general] How to disable systemd-tmpfiles-clean.timer
On Thursday 08 May 2014 09:53:41 Lukas Jirkovsky wrote: > On Thu, May 8, 2014 at 9:46 AM, Christos Nouskas wrote: > > On 8 May 2014 09:43, Olivier Langlois wrote: > >> Since a recent update (I have first noticed a couple of weeks ago this > >> new systemd enhancement), systemd started to automatically clean /tmp > >> directory daily. This is not something that I like as I prefer to decide > >> when to clean up and to manually perform the clean up. The /tmp directory is intended for temporary files, after all. If you need them to stick around, I'd recommend using /var/tmp. But yeah, masking the unit file should solve this for you, I think. > > I'm sorry I don't have a solution to your problem (which is also mine > > as I tend to keep a lot of files in /tmp...) but the invasiveness of > > systemd is just outrageous and, allow me to say, not KISS at all, i.e. > > do one thing and do it well [0]. First it was udev, next dbus, then > > journal logs, then timers, now automatic /tmp cleaning. What's next, > > mandatory reboot on each update? For those of us that run systems that are up for months at a time between reboots, relying on a reboot to clean out the cruft that accumulates in /tmp is not too elegant. Bear in mind that systemd itself is a set of separate tools, each performing one job and performing it well, in the UNIX tradition. It just so happens that the task that the systemd init daemon does is to manage and run many unit files (each doing one thing and doing it well), resulting in a well-managed system, in the UNIX tradition. Paul
Re: [arch-general] Optimizing boot
On Wednesday 30 Apr 2014 23:26:48 Rodrigo Rivas wrote: > Although the original problem has already been solved, I'll post my > trick to debug this kind of issues with systemd: > > * Before doing the thing that causes the problem run as root > `systemctl start debug-shell`. If the problem is in the boot sequence, > then run `systemctl enable debug-shell` and then restart. > * That unit will open a root shell in TTY9, so beware of the security > issues if you let that enabled. This shell will be enabled from the > early boot until the final shutdown. > * When the system hangs, switch to TTY9, with Alt+F9 or Ctrl+Alt+F9 > and get access to the debug shell. There you can run `systemctl > list-jobs` or `journalctl -b` to see what is wrong with your system. Very useful; thank you. I wonder if you might write that up on the Wiki page for systemd? Paul
Re: [arch-general] Optimizing boot
On Wednesday 30 Apr 2014 11:46:03 Mauro Santos wrote: > Check the output of journalctl and look for lines with timeout (use grep > -i timeout). > > I've experienced this before (90 seconds timeout) and I found out that > some systemd service related to the user session was not terminating, > and systemd waits for it until the timeout elapses. > > This happened to me when I had the rootfs in a f2fs partition, ext4 and > btrfs don't seem to trigger this problem. The workaround I used at the > time was to extend the unit file by explicitly adding a shorter timeout > 10~15s. Thanks, this got me on the right track. It was indeed nothing specifically to do with shutdown, but just a custom unit I'd written for fcgiwrap. Looks like there was some bad interaction between systemd trying to kill all the process tree and the master process trying to keep the workers alive. The unit was timing out (90 seconds, as you said). Fixed by adding: PostExec=/usr/bin/kill $MAINPID Reboot seems to be fine now. This was one of those things I assumed would be messy until I actually took the time to look into it :p That'll teach me to test custom units a little more carefully! Thanks, Paul
Re: [arch-general] Optimizing boot
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
Re: [arch-general] Qt4 / Qt5 package naming
On Friday 18 Apr 2014 10:29:56 Jerome Leclanche wrote: > Hi > > With Qt5 becoming more and more available throughout Qt apps > (especially as KDE progresses into the switch), I think it's time to > consider adopting an updated naming scheme. > > IMHO: > - Qt4 apps should use the -qt4 suffix > - Qt5 apps should not use any suffix or prefix > - Qt libraries should probably use a qt- prefix. (eg what is currently > qt5-base, qt5-doc etc should become qt-base, qt-location). Or > alternatively, no prefix at all and use upstream naming scheme > (qtbase, qtlocation, ...) I'm not a big fan of this transition happening for every major Qt release. Is there a significant downside to keeping both -qt4 and -qt5 in package names? Paul
Re: [arch-general] graphical display management
On Thursday 27 Mar 2014 16:45:35 message wrote: > On 2014-03-25 15:59, arch-general-requ...@archlinux.org wrote: > > -- > > > > Message: 1 > > Date: Mon, 24 Mar 2014 22:49:06 +0100 > > From: Jakub Klinkovsk? > > Subject: Re: [arch-general] graphical display management > > > >> Interestingly, 'su a' results in the cursor 'pwd' to be the root home > >> directory and not '/home/a'. > > > > This is the expected behaviour. Just run the command 'cd', without > > arguments it > > will get you into the home directory, which should be '/home/a'. Or run > > 'su -l a'. > > I would have expected the home directory for 'root' _not_ to be > accessible to other users. By "root home directory", do you mean "/" or "/root"? You are correct that "/root" should only be accessible by root. If the "pwd" command returns "/root" and "whoami" command does not return "root", then there's something wrong with your directory permissions. Paul
Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration
On Thursday 27 Mar 2014 09:07:23 Nicolas Iooss wrote:
> c) Create a package ("linux-src"?) which install the kernel sources
> and provides an easy way to customize the config before making the packages
> (with pkgbuild). Currently linux-grsec AUR package provides this feature by
> using the MENUCONFIG environment variable [5].
One of my machines requires a patched kernel, but I've never felt the need for
a linux-src
package. I use Yaourt as an ABS client, but there are others available:
# yaourt -G linux
# cd linux
--- do patching ---
# makepkg
The PKGBUILD even contains instructions on how to tweak the configuration, if I
remember correctly.
Paul
Re: [arch-general] tap device
On Thursday 20 Mar 2014 11:07:55 arnaud gaboury wrote: > I decided, when writing the wiki, to setup the container network > static IP (example given) INSIDE the container. > This approach solves the interfaces being DOWN issue for any network > profile and sounds in fact a more best-practice. > TY for your comments. Ah, excellent. That's good news :) And thank you for doing a wiki write-up. I'm sure that'll help lots of people in future. Paul
Re: [arch-general] user management error
On Wednesday 19 Mar 2014 20:04:27 message wrote: > On 2014-03-18 13:01, arch-general-requ...@archlinux.org wrote: > > -- > > > > Message: 7 > > Date: Tue, 18 Mar 2014 12:30:34 +0100 > > From: Ralf Mardorf > > Subject: Re: [arch-general] user management error > > > > You can't login as user, you log in as root. There seems to be a > > serious > > language barrier between you and the Arch community. > > OK: for archlinux, the first sign-in must be as root? > > > I assume we are talking about tty, no display manager is involved? > > I tried what I think was lxdm, but dvorak recognition fails, so > un-installed. Hi "message" (sorry, I can't figure out what to call you!), It would be really helpful to us if you could take a breath and carefully explain what your problem is, along with exact steps you're going through. It's really important that you don't assume something is obvious: so far, we're all pretty confused, because we're only getting little bits and pieces of information, and we're not getting the details and actual facts that we need in order to help you. Thanks, Paul
Re: [arch-general] Configuring enabled services
On Wednesday 19 Mar 2014 12:52:55 Gesh wrote: > 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 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
Re: [arch-general] user management error
On Tuesday 18 Mar 2014 10:28:05 message wrote: > No, the system does not start as root. > > After many reboots, am unable to sign-in directly as normal user 'a'. > Have to sign in as 'root' (command 'su' not recognised), then change to > 'a' using 'su a'. Access to /home directory 'a' (/home/a) is successful. What do you mean by "command 'su' not recognised"? Is this a message displayed when you try to log in as "a"? Clearly 'su' does work, as you say you can use it after logging in as root. >From your root account, can you do "passwd a" and set a new password for the >"a" account to see if that helps? If that's no good, can you show us the relevant line in /etc/passwd, so we can check it looks OK? (The password isn't stored in there, as has been explained already.) Paul
Re: [arch-general] tap device
On Monday 17 Mar 2014 12:00:10 Mauro Santos wrote: > I suspect we might have been talking about 2 different things all along. > What I and Arnaud have been talking about is the tap interface on the > host, not the interface inside the container, which of course should be > properly configured by the OS inside the container. > > The OS inside the container has no way to bring the tap interface on > the host up so there would be no network connectivity even though the > interface on the container side was properly configured and brought up. That would indeed make sense, but when I asked about this: On Wednesday 12 Mar 2014 17:32:27 arnaud gaboury wrote: >> In that case, I'm curious to find out if you find that setting the host0 >> interface up in the container also brings the vb-dahlia interface up on >> the host? > > On container : > > gab@dahlia ➤➤ ~ % ip addr > 2: host0: mtu 1500 qdisc > pfifo_fast state UP group default qlen 1000 > link/ether 56:84:f7:39:43:c7 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.94/24 brd 192.168.1.255 scope global host0 >valid_lft forever preferred_lft forever > inet6 fe80::5484:f7ff:fe39:43c7/64 scope link >valid_lft forever preferred_lft forever > > gab@dahlia ➤➤ ~ # ip link set dev host0 down > gab@dahlia ➤➤ ~ % ip addr > 2: host0: mtu 1500 qdisc pfifo_fast > state DOWN group default qlen 1000 > link/ether 56:84:f7:39:43:c7 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.94/24 brd 192.168.1.255 scope global host0 >valid_lft forever preferred_lft forever > > Now looking on host : > gabx@hortensia ➤➤ ~ % ip addr > 4: vb-dahlia: mtu 1500 qdisc > pfifo_fast master br0 state DOWN group default qlen 1000 > link/ether 8e:a4:c3:8c:cc:89 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.94/24 brd 192.168.1.255 scope global vb-dahlia >valid_lft forever preferred_lft forever > inet6 fe80::8ca4:c3ff:fe8c:cc89/64 scope link >valid_lft forever preferred_lft forever > > > It was UP before I brought vb down. So you have your answer : yes. ...buy maybe it doesn't work the other way---bringing the interface up after boot? Anyway, this was just a matter of curiosity for me, really. I'm glad you guys got things working the way you wanted. Paul
Re: [arch-general] tap device
On Monday 17 Mar 2014 09:55:11 arnaud gaboury wrote:
> > I guess someone will have to ask about it, either in the mailing list or
> > irc, I haven't done so before because systemd-{nspawn,networkd} have
> > lots of new functionality and I'm not sure I understand them all.
>
> After I related this issue (interfaces not being UP) on the
> systemd-devel mailing list, Tom Gundersen did a commit yesterday nite
> to change this behavior. So if you run systemd-git, just upgrade and
> interfaces will now be UP, and you will be able to get rid of your
> hack.
I don't get this: it seems normal to me that the interface would be down until
it's
configured by the container, pretty much like on a normal machine. The only
situation
in which you can expect an interface to be up already is in a network-booting
situation,
in which the initramfs configures the interface. In a virtualised situation,
this is like the
host configuring the container's interface for it.
Anyway, no big deal either way for me.
Paul
Re: [arch-general] doubts about rolling release
On Wednesday 12 Mar 2014 15:21:23 Ary Kleinerman wrote: > I'm thinking to use Arch for an Asterisk server. Nowadays I'm using > Ubuntu 12.04LTS, but I can see all distribution changing to the new > init system (systemd). I wanna change all my scripts to be compatible > with systemd. Furthermore, my services use MySQL, so I think it's a > good moment to migrate them to MariaDB. In short, I'll use Arch but > I'll have a virtual server (for testing purposes) to make change there > and then if all go okay, I'll apply the updates to the production > environment. This will work fine so long as you're aware that you can't install an Arch system and then forget about it for a few months. You have to update it every couple of weeks, at least. It needs more regular care than Ubuntu, or you could make things hard to yourself when you do come to update it. FYI, I think MariaDB is a drop-in replacement. Even the tools still use the "mysql" name; e.g. mysql_upgrade. You probably don't need to do anything special in your scripts. Paul
Re: [arch-general] tap device
On Wednesday 12 Mar 2014 17:32:27 arnaud gaboury wrote: > It was UP before I brought vb down. So you have your answer : yes. OK, so in that case, I'd recommend not doing anything special on the host to bring the vb- dahlia interface up. It's behaving just like a normal interface would on a real system: the interface should be brought up and configured as normal in the container; the host doesn't need to do anything special. So you should have this situation: The host has configuration that creates a bridge br0, containing only the physical interface enp7s0. The bridge should be given the IP address that you want the host to have. When the container is started, using --network-bridge=br0, the host automatically creates the vb-dahlia interface and adds it to the br0 bridge. No additional configuration is necessary on the host. The container should configure its network exactly as for a normal, non-virtualised system. It can use DHCP if necessary, in which case it will receive an IP on the same network as the host. Conceptually, they are connected to the same network via a hub/switch. Paul
Re: [arch-general] tap device
On Wednesday 12 Mar 2014 16:01:00 arnaud gaboury wrote: > See my previous post : I want to learn. Then, the container will one day be > a production server. So my idea is to test now everything, then take a > snapshot and build a prod server with much more complicated network > services and settings. OK yeah, that's also a good reason :) In that case, I'm curious to find out if you find that setting the host0 interface up in the container also brings the vb-dahlia interface up on the host? I think it would be best-practice to set the network configuration inside the container, if possible. That way, you can move the container from host to host without needing to perform any additional configuration on each host other than starting the container. After all, the container's IP is related to the container, not to the host, so it makes sense for its configuration to live with the container. Paul
Re: [arch-general] tap device
On Wednesday 12 Mar 2014 14:21:05 Mauro Santos wrote: > > Can I ask you both why you chose this route of creating a private network? > > As far as I can tell, by default systemd-spawn will allow the container > > to use the host's interface. I would have thought that would be adequate > > for most usecases? > > Because I have both a virtual machine and container that need to talk to > each other. Yeah, that sounds like a sensible reason; thank you. I believe Arnaud's usecase is a single container with no particularly special connectivity requirements (as far as I can tell). I'm worried that he's making his setup a lot more complicated than it needs to be. Paul
Re: [arch-general] tap device
On Wednesday 12 Mar 2014 15:20:01 arnaud gaboury wrote: > > Can I ask you both why you chose this route of creating a private network? > > As far as I can tell, by default systemd-spawn will allow the container > > to use the host's interface. I would have thought that would be adequate > > for most usecases? > > > > Paul > > My first tests with nspwan/networkd, with a very minimal configuration > (just one eth netcl profile) left me with a working network on > container, but as you said, the container was using host interface > (enp7s0 in my case). Thus, same IP for both and no container network > "isolation". > > From SYSTEMD-NSPAWN(1) > >--private-network >Disconnect networking of the container from the host. This > makes all network >interfaces unavailable in the container, with the exception > of the loopback device and >those specified with --network-interface= and configured > with --network-veth. > > That is exactly what I wanted. In my case, as the container is aimed > at hosting various web apps with a static IP, I wanted to isolate the > container network from the host one. OK, so in fact you did have an extra requirement that you wanted to use a separate IP address in this container? Is that an important requirement? Also, as I stated earlier, I think you should be using --network-bridge, not --private-network. Paul
Re: [arch-general] tap device
On Wednesday 12 Mar 2014 14:06:30 Mauro Santos wrote: > No netctl here :) > > I systemd-networkd enabled on boot and 3 files in /etc/systemd/network > > > cat brkvm.netdev > > [NetDev] > Name=brkvm > Kind=bridge > > > cat brkvm.network > > [Match] > Name=brkvm > > [Network] > Description=Bride for use with virtual machines and containers > Address=192.168.56.1/24 > > > cat vb-veth.network > > [Match] > Name=vb-* > > This last one is sort of a hack to bring the network up as it shows up, > I suppose systemd-nspawn should do it by itself, this might be a bug, > unless there is a good reason not to bring the network up automatically. > > Inside the container I do manual setup of the network address since I'm > not actually booting it. > > Mind you that you may have to do systemctl daemon-reload (not really > sure if this one is needed) and restart systemd-networkd for any changes > to make effect. Can I ask you both why you chose this route of creating a private network? As far as I can tell, by default systemd-spawn will allow the container to use the host's interface. I would have thought that would be adequate for most usecases? Paul
Re: [arch-general] tap device
On Wednesday 12 Mar 2014 14:48:38 arnaud gaboury wrote: > Right. I am left after I boot my machine (the host) with this : > > 4: vb-dahlia: mtu 1500 qdisc noop master br0 > state DOWN group default qlen 1000 > link/ether 62:a2:6b:f4:0f:87 brd ff:ff:ff:ff:ff:ff > > I have to manually > # ip link set dev vb-dahlia up > > to get the network working on the container : > > 2: host0: mtu > 1500 qdisc pfifo_fast state UP group default qlen 1000 > link/ether 5a:51:a2:a2:b5:fb brd ff:ff:ff:ff:ff:ff > inet 192.168.1.94/24 brd 192.168.1.255 scope global host0 >valid_lft forever preferred_lft forever > inet6 fe80::5851:a2ff:fea2:b5fb/64 scope link >valid_lft forever preferred_lft forever Does it work if you do "ip link set host0 up" in the container? I think that would be a better solution. > Ah? I have two netctl profiles, one for my physical eth (enp7s0) with > no ip, one for bridge (br0) with enp7s0 binded to. > So you mean you don't have any bridge profile managed by netctl ? As far as the host is concerned, I think you should consider the bridge as if it were the only interface. The enp7s0 interface is part of the bridge and should not be configured in addition to being joined to the bridge. So yeah, I would get rid of the physical enp7s0 configuration, and leave only the bridge configuration on the host. Paul
Re: [arch-general] tap device
On Tuesday 11 Mar 2014 18:03:20 arnaud gaboury wrote: > > OK, so you really just need basic internet connectivity; you don't > > have any special filtering requirements. When you boot the > > container, can it see the enp7s0 interface? That is, is the enp7s0 > > interface visible both from the host and from the container? > > no. On container, I just see hos0, what is expected So you're using --network-veth when you launch the container? As far as I can tell, you don't need a tap interface at all; that will be handled automatically by systemd. I think all you need to do is create the bridge br0, binding the physical interface enp7s0 on its own (a bridge containing only the host's adaptor). Then, you launch the container with -- network-bridge=br0. That will automatically add the container's interface to the bridge. I'm not sure if the container will be aware of the bridge's IP address at this point. I'd want to check with the "ip a" command to see if it's listening on the same IP address on host0 and check to see if it has connectivity before assigning an IP to the host0 interface inside the container. Paul
Re: [arch-general] tap device
On Tuesday 11 Mar 2014 15:45:19 arnaud gaboury wrote: > The container is dedicated to be a test server for months before I set > up a production server (not on my machine this time !). A lot of web > services will be hosted on the container. > The container is a way to test my settings for web apps and coding OK, so you really just need basic internet connectivity; you don't have any special filtering requirements. When you boot the container, can it see the enp7s0 interface? That is, is the enp7s0 interface visible both from the host and from the container? Paul
Re: [arch-general] tap device
On Tuesday 11 Mar 2014 13:06:23 arnaud gaboury wrote: > > systemd-networkd is still really new. If you're having difficulty with it, > > I recommend simply using netctl, which is a bit more mature. > > I do for part of the setup on host. I am trying to do zero network > config on container, thus the use of networkd. But I can use netctl > inside the container, you are right > As far the rest, I'm afraid I don't know. Before any > > > manual configuration, did you see any network interfaces in the container? > > I'm losing track of what you've created and what systemd creates for you > > when you spawn the container. (I think you're using systemd-nspawn, > > right?) > > yes I'm not sure what you mean by zero network config. Do you mean you want to set up the tap interface entirely on the host, along with a static IP, and then the container simply attaches to that tap device when it boots? I guess that's possible. Can I ask what you're trying to achieve in terms of this network setup? Are you just after straight-forward internet connectivity, or are you planning to filter packets going in and out of the container? For the simple usecase, I think you can simply use the normal host interface from inside the container, though you can't modify it. Paul
Re: [arch-general] tap device
On Tuesday 11 Mar 2014 11:06:32 arnaud gaboury wrote: > > Hi Arnaud, I don't think you need the /etc/netctl/ethernet profile at all. > > The enp7s0 interface is being absorbed into the bridge, and so should not > > be considered on its own any more. Otherwise, this looks OK. Are you > > seeing any connectivity problems? > Thank you. > Btw, as I was thinking using the tap0 interface for the container with > systemd-networkd when I realized systemd.netdev does not support tap > interface ! > So: > 1- i do not use systemd-networkd and configure network inside > container using tap0 (I spent so much time understanding networkd I > will not favor this way) > 2- I use networkd with a bridge br0 bind to "enp7s0" and > "my_container_interface". I am still not sure what kind of interface I > shall put for container. > I know "vb-container_name" works as interface (this is a virtual > bridge), when enabling the 80-container-host0.network, but I need to > modify systemd-nspawn@.service and append --network-bridge=br0 in the > line ExecStart. This does sound like a dirty hack. > In this case, I will have host0 on container, and br0 on host. > Furthermore, the virtual bridge notion sounds weird to me. A bridge is > already a virtual interface, so with the virtual bridge, it sound we > are at virtual layer 2 !! systemd-networkd is still really new. If you're having difficulty with it, I recommend simply using netctl, which is a bit more mature. As far the rest, I'm afraid I don't know. Before any manual configuration, did you see any network interfaces in the container? I'm losing track of what you've created and what systemd creates for you when you spawn the container. (I think you're using systemd-nspawn, right?) Paul
Re: [arch-general] tap device
On Monday 10 Mar 2014 18:57:38 arnaud gaboury wrote: > Hi, > > I am setting up a network for a container. > > I have a bridge br0 with a eth adapter "enp7s0" and a tap device "tap0" > > > *** > /etc/netctl/bridge > Description="Bridge connection" > Interface=br0 > Connection=bridge > BindsToInterfaces=(enp7s0 tap0) > IP=static > Address='192.168.1.87/24' > Gateway='192.168.1.254' > DNS='192.168.1.254' > > /etc/netctl/ethernet > Description='ethernet connection' > Interface=enp7s0 > Connection=ethernet > IP=no > IP6=no > > /etc/netctl/tuntap > Description='tuntap connection' > Interface=tap0 > Connection=tuntap > Mode='tap' > User='nobody' > Group='nobody' Hi Arnaud, I don't think you need the /etc/netctl/ethernet profile at all. The enp7s0 interface is being absorbed into the bridge, and so should not be considered on its own any more. Otherwise, this looks OK. Are you seeing any connectivity problems? Paul
Re: [arch-general] The pacman upgrading error has been solved
On Monday 10 Mar 2014 16:20:25 Cao, Renzhi wrote: > Thanks Paul! >The reason why I copy /bin/* to /mnt/bin is my/mnt/bin is not exists. > I don't know what happens, it seems this is deleted when I try to fix my > problem. I will see if my system works well, if not, I will be back again > :) This is because everything in /bin was moved to /usr/bin, and /bin was supposed to become a symlink to /usr/bin. When you do this: ls -la / Do you see: /bin -> usr/bin /lib -> usr/lib /lib64 -> usr/lib /sbin -> usr/bin Hopefully, you will. If not, you need to do some more work. >Indeed, I learn a lot and now becomes more confident! I will tell my > adviser to do the backups for all the systems. If someday I lose the data, > I will share that "good news" to you immediately, and I believe that will > make a lot of fun for you and the community! :) Paul
Re: [arch-general] doubts about rolling release
On Monday 10 Mar 2014 15:40:13 John WH Smith wrote: > By the way, I > strongly believe you will fix things faster if you like your environment > (I assume it is Arch here, of course). Being used to your system is much > more important than its stability when it comes to your sysadmin speed > of reaction. Yes, that is some top-quality wisdom right there. Paul
Re: [arch-general] The pacman upgrading error has been solved
On Monday 10 Mar 2014 15:48:15 Cao, Renzhi wrote: > I really appreciate Emil Lundberg, Paul Gideon Dann, Temlin Oliv?r, , > Guus Snijders' great suggestion, you are right, that's my fault to use > /dev/mapper/arch_root_image as the root partition, now I can login the > system,it seems my system is working now. There are two things I do today > (my mistakes) based on your suggestion: 1. Instead of using /dev/mapper/ > arch_root_image, I use /dev/sda3 as my root partition, and mount first. 2. > I copy the files /bin/* to /mnt/bin, so that the error message "failed to > run command /bin/sh, no such file or directory" will not exists. I don't > see this solution in the internet, I am just think it by myself, so maybe > this can help other people with the same problem if what I have done is > correct. That's great news :) The solution with copying /bin/* to /mnt/bin is a very radical solution, and I wouldn't normally recommend it, because potentially it could cause other problems (overwriting files that belong to many packages). That's because /bin/* was the files from the live CD, and /mnt/bin is your installed system, and they will have different versions of many packages. I'm glad it worked for you, though! If your system is working, any difference in the version of packages will be resolved naturally as you continue to update your system and new packages are installed, and those files are replaced. > I don't know how to appreciate all of you, the community. I am so glad to > fix this problem now. During the process, I have learned a lot of things, > and become more familiar with arch linux, and also love it more (I always > love the things more when I get more familiar with). The feeling is > strange, at beginning, I see that problem, I have no idea, and become very > worried about that. I am considering that time I am failers, just hoping > some angel can come and solve that problem for me ... But now, I start > learning these things, about what's happening, and with your help, I become > more and more confident. Thank you all. I hope my experience can benefit > other people, especially the new archer, I want to tell you, don't be > afraid, go ahead, start learning, asking good question, and then finally > you can fix your problems! The last thing I will do is format the window > system of my laptop, install arch linux :) This a really great result. What I love most about ArchLinux is that with some curiosity and courage, anything about the system can be understood, and a lot can be learned! Make sure you keep taking backups of your data, though! It's fun at all if you lose all your data :p Paul
Re: [arch-general] doubts about rolling release
On Monday 10 Mar 2014 10:08:06 y...@marupa.net wrote: > I love Arch, but not for servers. I prefer Debian on my server. Despite all > the dire warnings given to keep an eye on Arch's web site about certain > upgrades, its still all too frequent user intervention is necessary where > nothing is stated on the website at all about potential problems of that > particular upgrade. Oh yeah, you need to have your head screwed on for each update. That is certainly a bad thing if you just want a simple Samba or PHP web server, for instance. > Production environments do not need that sort of support. While latest and > greatest and the newest features might sound great for the desktop, on > servers it's not that critical, and long term support and a need for a > release to "stand still" is much more important. It depends on the usecase. For me, I rely on the ease with which I can modify and rebuild packages on Arch. There's a relatively complex interaction on this server, and I like to know that I'm in control. For instance, the Ruby rmagick gem doesn't like the imagemagick package that Arch ships, so I have to do a small tweak to the PKGBUILD and build it myself. I don't get that kind of flexibility with Debian. (I'm sure it's technically possible, but Debian isn't geared toward that workflow like Arch is.) > This is why I prefer Debian on my server: The only updates I should want on > a server are those that improve the integrity and stability of its > environment. I'll happily wait 2-3 years before I go for the major upgrades > that will change the environment. Even then I might wait for "oldstable" to > hit its EOL before upgrading, because not getting support at all is even > worse. > > At that point I can be confident that most of the upgrades won't need my > intervention to work, save for a few things, thanks to testing. For a straight-forward server that I want to set up and forget, I totally agree. For a server that I use for continuous development of internal tools, I think I'd find Debian too brittle. > Arch is great for power desktop users and those who want to be assured that > they don't have to wait for months to years to get the latest Firefox or > KDE/GNOME versions. But I've used it on servers jst enough to know it's > not really suitable for that role. I'd be using 3-year-old versions of Nginx, Redis, and Ruby if my server were Debian. As a developer, that's a real drag. It's just a different set of requirements, I think. Paul
Re: [arch-general] Cannot recover pacman upgrade fails problem
On Monday 10 Mar 2014 14:52:23 Cao, Renzhi wrote: > Hi, > Thank you for giving suggestions, I have tried the one you suggest, and > here is the result: #ls /mnt/sda2 > boot/,grub/,home/,initramfs-fallback.img,,initramfs.img,lost+fount/,memtest8 > 6+/,syslinux/,vmlinuz-linux #ls /mnt/sda3 > /boot,dev/,etc/,home/,opt/,lost+found/,proc/,root/,run/,srv/,usr/,var/,sys/. > > > I am considering sda2 as boot partition, sda3 as my home directory, which is > the highest level of my system before it crashes. And I try the following > two options: > > 1. > #mount /dev/sda2 /mnt > #mount /dev/sda3 /mnt/home > #arch-chroot /mnt > mount: mount point /mnt/proc does not exist > Error => failed to set up API filesystems in arch-chroot > > 2. > #mount /dev/sda3 /mnt > #mount /dev/sda2 /mnt/boot > #arch-chroot /mnt > failed to run command /bin/sh, no such file or directory > > When I try using /dev/mapper/arch_root-image as root partition, the > arch-chroot works, that's why I am using that. Is there any problem in my > command? Thank you very much! What do you get when you run the "lsblk" command? It looks to me as though: /dev/sda3 => / /dev/sda2 => /boot The lsblk command should help a lot if the device-mapper is involved (e.g. if you used LVM). What's the history here? Is this an old box that you set up with Arch as a hobby project and now you just got back to it? Why was there such a long wait before an update? Do you remember the choices you made when you set it up (e.g. partitions etc...)? Paul
Re: [arch-general] Cannot recover pacman upgrade fails problem
On Monday 10 Mar 2014 03:51:04 Cao, Renzhi wrote: > Hi, all: > > I really have no idea for the pacman upgrading fails issue, so I > summarize the problem I meet, and the things I try, if any one can give me > suggestions of what I miss something or I do something wrong, I really > appreciate, if not, I hope this summation can benefit some other people who > meets the same problem. I don't think you'll be able to get your system to boot at all until everything is up-to-date. You'll need to install filesystem before rebooting. Have you managed to move everything into /usr yet? The following directories should now be symlinks: /bin -> usr/bin /lib -> usr/lib /lib64 -> usr/lib /sbin -> usr/bin Have you managed to get that far? Paul
Re: [arch-general] doubts about rolling release
On Friday 07 Mar 2014 15:09:27 Ary Kleinerman wrote: > Hi, > I'm a new Archer and I'm planning to install arch linux in a production > server environment, but I have doubts because Arch is a rolling release. My > question is: what does it happen when there are big changes? e.g. changes > in the filesystem or when Arch has started using systemd. > Regards, > Ary I use Arch in production for several of our company's internal tools (bug tracker, SVN, etc...) I went through the systemd and /usr transition without a hiccup. The only downtime was the required reboot, I think. That's because I had been through the transition on my own machine and was well prepared. I've rarely had any issues caused by Arch updates. You do need to be aware of what packages to hold back (IgnorePkg in /etc/pacman.conf), which will depend on what you're using the server for. Finally, be sure to use a monitoring system. I use monit and ganglia. Together, they help me keep an eye on things like disk usage trends, and notify me of various causes for concern. I use rsnapshot for local iterative backup, along with a custom script that moves an archive onto a remote server that deals with getting it onto tape. (IT is all Windows-based; I'm pretty much the only Linux guy.) Paul
Re: [arch-general] Problems of using pacman and updating the filesystem
On Friday 07 Mar 2014 09:26:19 Caorenzhi wrote: > Thank you! I remember when I run the command to find out the packages I > should remove, it shows: lilo, grub-common, initvlinux( something like > this), but I don't know how to move them to /usr/bin. I try directly mv > lilo to /usr/bin, and use the command to search which package I should > remove, it seems the lilo is still there. And I don't know which files > belong to initvlinux, or grub-common, there are a lot of files start with > grub- , I am afraid I remove it wrongly. I'm a bit worried that this system may not have been updated even since the switch to systemd :s Next time you're at the system, can you have a look at /var/log/pacman.log: # less /var/log/pacman.log Press SHIFT-G to go to the bottom, and scroll up until you can see the date of the last time you used pacman to update the system (before this last time that caused the mess). If the last time you updated was before 2012-11-04, there's a good chance you never made the switch to systemd, which will make things even harder for you. Paul
Re: [arch-general] Problems of using pacman and updating the filesystem
On Friday 07 Mar 2014 09:12:39 Caorenzhi wrote: > Thank you Paul, I will check it in my lab later and tell you the details. I > try add ip eth0 yesterday , and the system says there is no eth0. In that case, you need to do: # ip link to see a list of your network interfaces. It might not be called eth0, but hopefully one of them will correspond to the wired interface, assuming this is a computer that can in fact be plugged in with a cable. Paul
Re: [arch-general] Problems of using pacman and updating the filesystem
On Friday 07 Mar 2014 08:46:02 Caorenzhi wrote: > Thank you for your good suggestion! I think I can use pacman to remove the > packages, however, I cannot connect to Internet after chroot, so cannot use > pacman to update. Do you have any idea? Assuming you can plug your computer in with an ethernet cable, you could try: # ip link set eth0 up # dhcpcd eth0 That will hopefully give you access to the internet. Paul
Re: [arch-general] systemd-nspawn/systemd-networkd/
On Friday 07 Mar 2014 12:28:56 arnaud gaboury wrote: > I read a lot, especially when it comes to networking. As for me, it is > the trickiest part of administrating my machine. Yeah, networking can get complex very quickly. (I'm by no means an expert either!) > I found many posts > asking help about bridge, and I realized I was far from being the only > one to have trouble with this notion. This looks pretty good when you have time, at least for understanding some more theory: http://www.linuxjournal.com/article/8172 Paul
Re: [arch-general] systemd-nspawn/systemd-networkd/
On Thursday 06 Mar 2014 23:46:59 arnaud gaboury wrote: > I finally managed to boot the container with a working network and a > static IP. I only used netctl, as systemd-networkd is still a mistery > to me. [...] > It lacks in > fact a good example, from the container creation to the network setup. > But maybe shall all this be written in a WIKI. I've had a quick look at systemd-networkd, and I don't think it would be significantly different to set up than netctl in your case. I think the problem was one of theory: I don't know how much reading you've done, but you need to understand some theory of the networking stack, network interfaces, bridges etc... before you can make a sensible configuration. I think that's beyond the scope of the documentation for most of these tools, although it would certainly make sense for the wiki to document some common use-cases. Paul
Re: [arch-general] bridge with netctl
On Thursday 06 Mar 2014 23:01:30 arnaud gaboury wrote: > On Thu, Mar 6, 2014 at 8:00 PM, arnaud gaboury > wrote: > >> 1) Two new virtual interfaces are create: one that is visible to the > >> container, and one that is visible to the host. The host now has two > >> interfaces, which may be bridged, or it may act as a NAT router on the > >> interface that goes to the container. The container only sees the one > >> interface, and uses perfectly normal means to obtain an IP address.> > > That's correct. When I boot the container, a new interface "vb-dahlia" > > appears on the host, and on the container side, i have a "host0" > > interface. > > > > So I guess I must have a netctl br0 profile with this line : > > > > BindsToInterface=(enp7s0 vb-dhalia) > > It took me a while, but I have now a working bridge on Host machine, > with a static IP and a working ethernet connection on container, with > a static IP. > > Thank you for your help You're welcome, Arnaud. Glad you got it working in the end. Paul
Re: [arch-general] bridge with netctl
On Thursday 06 Mar 2014 16:14:19 arnaud gaboury wrote: > > This configuration make no sense whatsoever. > > > > 1) You create a bridge with no ports. What purpose does it serve? > > 2) If you want to add enp7s0 as a port, why do you have a configuration > > for enp7s0? If an interface is a bridge port, it cannot be used for IP > > traffic, so assigning it an IP is pointless. > > If I understand correctly, in fact I took the set up upside down. I > tried br0 ---> enp7s0 when in fact the scheme is > > |-> dev 1 > > enp7s0 > bridge br0 | > > |--> dev 2 > > Am I correct in this scheme? What do you mean by dev 1 and dev 2? Paul
Re: [arch-general] bridge with netctl
On Thursday 06 Mar 2014 14:03:54 arnaud gaboury wrote:
> I am running a machine "hortensia" with a container "dahlia". As the
> container will be a server, I want to have one IP for hortensia and
> another one for dahlia.
>
> On hortensia, with dhcpcd.service and systemd-networkd both disabled,
> I start at boot two netctl profiles.
>
> /etc/netctl/bridge-hortensia
> Description="Bridge connection to container"
> Interface=br0
> Connection=bridge
> BindsToInterfaces=()
> IP=no
>
> /etc/netctl/static-hortensia
> Description='hortensia static ethernet connection'
> Interface=enp7s0
> Connection=ethernet
> IP=static
> Address=('192.168.1.87/24')
> Gateway=('192.168.1.254')
> DNS=('192.168.1.254')
Hi Arnaud. This doesn't seem right to me. The purpose of a bridge is to connect
several
interfaces together. Your bridge is not bound to any interfaces, so it's
effectively useless,
unless there's some special use of bridges I'm not familiar with.
Although I haven't played with containers much at all, I would expect it to
work in one of 2
ways:
1) Two new virtual interfaces are create: one that is visible to the container,
and one that is
visible to the host. The host now has two interfaces, which may be bridged, or
it may act
as a NAT router on the interface that goes to the container. The container only
sees the
one interface, and uses perfectly normal means to obtain an IP address.
2) No new interfaces are defined, and the host's interface is shared with the
container. In
this case, you will need to add another IP to the interface so that it'll
respond to both the
host's IP and the container's IP, and then either perform some kind of packet
filtering, or
simply ensure that the services on host and client are each configured to
respond only to
the desired IP.
Paul
[arch-general] KDE breakage with glibc 2.19-2
Is anyone else seeing breakage of KDE compositing with glibc 2.19-2? Large areas are unrendered: window contents and the plasma desktop are black, although my panel is visible. Seems OK when I turn of compositing. I've tried going back and forth, and it's definitely the glibc update that's causing the issue for me. Anyone else? Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 17:58:05 Damjan Georgievski wrote: > > Yeah, I think it's possible to get systemd to poll a script, or there's > > always cron (or a timer > > unit) that should allow us to manually inspect a process and restart it if > > necessary. But it > > would be cooler if there were shortcuts to features that we see in Monit > > and other similar > > systems; something like this in a unit file: > > > > MaxMemoryThreshold=100M > > MaxMemoryCheckInterval=30 > > MaxMemoryIntervalThrehold=2 > > > > The memory is then checked every 30 seconds. When the unit exceeds this > > amount of RAM > > for 2 successive intervals, the unit is restarted. > > there is setting of ulimits in systemd, it's much more brutal though, will > not wait for 30 seconds > > man systemd.exec Thank you; I didn't know about that, and it's very interesting. The limits are indeed a bit strict for server process monitoring. I imagine it would be really handy as a failsafe in embedded environments, though. The great benefit of them is that (as far as I can tell), it's the kernel that enforces the limits, so there's no polling involved. I suppose that the gold standard for monitoring would be a combination of the two: a userspace component (e.g. systemd or associated monitoring tool) registering to receive events from the kernel on certain resource thresholds for a process, so that e.g. time spent above RAM threshold could be monitored accurately in an event-based way, without polling. That would be awesome. Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 13:36:35 Denis A. Altoé Falqueto wrote: > On Thu, Feb 13, 2014 at 1:29 PM, Paul Gideon Dann wrote: > > Yeah, though actually I'm just really surprised that, given the incredible > > administrative benefits of systemd, there isn't currently anything that > > leverages it for actual process monitoring and reporting. As far as I > > can tell, systemd is also not yet able to automatically restart bloated > > or stale services (e.g. worker instances that may go haywire). Hopefully > > these things will come along now that "systemd --user" is maturing. > I think you can rely on software or hardware watchdogs, which are > supported by systemd. Yeah, I think it's possible to get systemd to poll a script, or there's always cron (or a timer unit) that should allow us to manually inspect a process and restart it if necessary. But it would be cooler if there were shortcuts to features that we see in Monit and other similar systems; something like this in a unit file: MaxMemoryThreshold=100M MaxMemoryCheckInterval=30 MaxMemoryIntervalThrehold=2 The memory is then checked every 30 seconds. When the unit exceeds this amount of RAM for 2 successive intervals, the unit is restarted. Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 16:05:05 Rodrigo Rivas wrote:
> Ok... I'll take the chance to practice my DBus abilities...
> It is a bit long, but it kind of works. Just replace the print() call
> with your favourite sendmail function and you'll get a notification
> every time any of the units specified in the command line changes
> status.
>
> HTH.
>
> #!/usr/bin/python
> from gi.repository import GObject
> import sys
> import dbus
> from dbus.mainloop.glib import DBusGMainLoop
>
> DBusGMainLoop(set_as_default=True)
>
> bus = dbus.SystemBus()
> systemd = bus.get_object('org.freedesktop.systemd1',
> '/org/freedesktop/systemd1')
> manager = dbus.Interface(systemd, 'org.freedesktop.systemd1.Manager')
>
> def GetPropChanged(obj, iface, propName, changes, invalids):
> if propName in invalids:
> return obj.Get(iface, propName,
> dbus_interface=dbus.PROPERTIES_IFACE) elif propName in changes:
> return changes[propName]
> else:
> return None
>
> def OnPropChanged(unit, name, iface, changes, invalids):
> if iface != 'org.freedesktop.systemd1.Unit':
> return
> state = GetPropChanged(unit, iface, 'ActiveState', changes, invalids)
> substate = GetPropChanged(unit, iface, 'SubState', changes, invalids)
> if state or substate:
> print('Status changed', name, state, substate)
>
> for unitName in sys.argv[1:]:
> unit = bus.get_object('org.freedesktop.systemd1',
> manager.GetUnit(unitName)) unit.connect_to_signal('PropertiesChanged',
> lambda a,b,c :
> OnPropChanged(unit, unitName, a, b, c),
> dbus_interface=dbus.PROPERTIES_IFACE)
>
> loop = GObject.MainLoop()
> loop.run()
Thanks Rodrigo; great work. I may come back to this in future if no "official"
solution
ever seems forthcoming.
Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 16:11:56 Thomas Bächler wrote: > Am 13.02.2014 16:05, schrieb Rodrigo Rivas: > > Ok... I'll take the chance to practice my DBus abilities... > > It is a bit long, but it kind of works. Just replace the print() call > > with your favourite sendmail function and you'll get a notification > > every time any of the units specified in the command line changes > > status. > > This isn't too long and it actually seems to work fine. > > I guess what Paul actually wants is a system where you would subscribe > to all services, not just some of them. This should be possible as well > with the API. Yeah, though actually I'm just really surprised that, given the incredible administrative benefits of systemd, there isn't currently anything that leverages it for actual process monitoring and reporting. As far as I can tell, systemd is also not yet able to automatically restart bloated or stale services (e.g. worker instances that may go haywire). Hopefully these things will come along now that "systemd --user" is maturing. I'm actually pretty excited about user-systemd. I'm implementing monitoring for long- running Ruby processes for a Rails app, and although the go-to tool for this in the Ruby world is "god", I've found it really icky and brittle, and really wish I could replace it with systemd, but for now I will make my peace. Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 13:41:21 Damien Churchill wrote: > You could use unit overrides[0] to add the OnFailure to provided > units. So should be able to set it up for any service you are > interested in receiving notifications for, I would assume. Yes, absolutely, but this only works for a subset of units: it wouldn't be practical to override every unit on the system in order to monit for failures. Currently, I have a cron job that runs "systemctl --failed" and mails me the output if it's not an empty list. It would be nice to have a more elegant solution than that to monitor for unexpected failures. Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 14:21:36 ushi wrote:
> Am 13.02.2014 13:04, schrieb Paul Gideon Dann:
> > Hello all,
> >
> > Does anyone know of any standard system for receiving notifications
> > from systemd for unit state changes? I currently use Monit for the
> > monitoring of many processes, and it'll e-mail me when things
> > happen (e.g. a process was restarted). Since switching to systemd,
> > it's felt a bit silly that for several processes, I'm having Monit
> > monitor them simply because systemd is unable to tell me it
> > restarted a unit. Monit isn't actually required to keep those
> > processes alive as it once was, because systemd can do that.
> >
> > Paul
>
> Hey Paul,
>
> Check out OnFailure=
>
> [Unit]
> Description="HTTP Service"
> OnFailure=mail-root@http.service
> ...
>
> The mail-root@.service is a generic oneshot service that mails you
> some stuff.
>
> [Unit]
> Description="Mailer"
>
> [Service]
> Type=oneshot
> ExecStart=/path/to/my/mail-script %i
>
> [Install]
> WantedBy=multi-user.target
>
> And your mail-script is somthing like...
>
> #!/usr/bin/env sh
>
> systemctl status "${1}.service" | \
> mail -s "Failed Service: ${1}" ad...@example.com
>
> See:
> http://www.freedesktop.org/software/systemd/man/systemd.unit.html#OnFailure=
Thanks ushi, that's certainly something. It looks promising for custom unit
files, but not
so great for catching unexpected unit failures. I'll definitely keep that one
in mind,
though.
Paul
Re: [arch-general] Systemd email notifications
On Thursday 13 Feb 2014 13:35:59 Thomas Bächler wrote: > Am 13.02.2014 13:04, schrieb Paul Gideon Dann: > > Does anyone know of any standard system for receiving > > notifications from systemd for unit state changes? I currently > > use Monit for the monitoring of many processes, and it'll e-mail > > me when things happen (e.g. a process was restarted). Since > > switching to systemd, it's felt a bit silly that for several > > processes, I'm having Monit monitor them simply because > > systemd is unable to tell me it restarted a unit. Monit isn't > > actually required to keep those processes alive as it once was, > > because systemd can do that. > > I'd place a bet on the systemd dbus API: IIRC, it exports the state of > each unit as a property and then emits the standard > org.freedesktop.DBus.Properties.PropertiesChanged signal when the state > changes. > > So, your task would be to subscribe to that signal and act on it. This > could be nicely done in python (and maybe someone has done it already). Agreed, but I'm baffled as to why there isn't already a well-known tool. To be honest, I'd have expected it to be important enough to be produced along-side the systemd project, probably with several backends for different notification systems. Paul
[arch-general] Systemd email notifications
Hello all, Does anyone know of any standard system for receiving notifications from systemd for unit state changes? I currently use Monit for the monitoring of many processes, and it'll e-mail me when things happen (e.g. a process was restarted). Since switching to systemd, it's felt a bit silly that for several processes, I'm having Monit monitor them simply because systemd is unable to tell me it restarted a unit. Monit isn't actually required to keep those processes alive as it once was, because systemd can do that. Paul
Re: [arch-general] Linux container
On Wednesday 12 Feb 2014 21:00:54 arnaud gaboury wrote: > > You'll have to build a custom kernel. > > ah... > Another new step for me. > fine, I learn, I learn. That's what makes ArchLinux so awesome: once you're done, your understanding will be greatly expanded. As you move from project to project, the curve flattens out, you find it easier to understand how everything is fitting together, and you suddenly discover that you've landed in the territory that most others consider "expert" :) Paul
Re: [arch-general] journalctl and I/O errors
On Thursday 30 Jan 2014 11:46:38 Nowaker wrote: > > A couple months ago, I started getting I/O errors (see below) whenever > > I tried to do journalctl > > You are able to read all the journald files, aren't you? You are running > cp -r so it looks like so. `cp` would die with non-zero exit status if > there were read errors I guess. If it's possible to read the file, > journalctl should not segfault IMO, so it should be OK to file an issue. IO errors can also cause a process to hang, and enter the dreaded "D" state. These processes usually can't be killed, because they're blocked in the kernel. Paul
Re: [arch-general] Deploy Arch linux to many virtual machines
On Thursday 23 Jan 2014 21:59:06 Plonky Duby wrote: > You can use docker. http://docs.docker.io/en/latest/installation/archlinux/ Thank you; I was not aware of Docker. It looks *awesome*. Paul
Re: [arch-general] Is out of source building still recommended with cmake in PKGBUILD scripts
On Tuesday 14 Jan 2014 23:17:53 Maxime Gauduin wrote: > It is indeed no longer required with VCS sources, and has never been with > tarballs since those are extracted every time you run makepkg so files you > might have changed are overwritten anyway. However I sometimes find useful > to keep doing that with cmake when you need to figure out why sth won't > build, because that way files generated by cmake at build time are in a > separate dir. Mmm, bear in mind that most cmake projects won't be tested with in-source builds. It's possible they might break. One possible scenario: files intended to be generated in the build directory could potentially match files that exist in the source directory (although that wouldn't be great practice), and bad things would then happen. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 11:03:32 Bigby James wrote: > That was how I discovered the multi-version dependencies: As pacman will > only allow a single version of a package to be installed on the system at a > given time, I was frequently alerted to "updates" of dependency gems I had > installed. Middleman depends on a later version of a particular library > than does Jekyll; if I update the gem via pacgem, Middleman will function, > while Jekyll will break. It simply wasn't possible to use both > simultaneously, and since I depend on Jekyll for work I do, that's > unacceptable. It's far simpler (in my opinion) to use "gem install" as > $USER to install to my /home directory and add the installation directory > to $PATH, as I'm the only one who uses my machine. In the event that gems > do (for whatever horrific reason) become unmanageable, one can simply nuke > the directory where they're installed and reinstall all necessary gems > rather quickly, without risk to the system at large. Thanks, Bigby, for articulating the point far better than I was doing :) I'd like to add to this that I also use Ruby for general scripting and monitoring on several servers that I maintain, mostly through cron jobs. These small system scripts run as root. I could install the gems into /root, but I prefer to have them installed system-wide, as they're more visible that way (element of least surprise), and means I can write and test the scripts as non-root first. That's why I use "sudo gem install" to manage system gems, and why I remove the --user-install option in my /etc/gemrc. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 17:58:59 Maxime Gauduin wrote: > I only use a few ruby packages. However, you said it yourself, ruby and > pacman both have different uses, my point was: do not change the content of > a dir managed by pacman, do so elsewhere. I'm not saying you shouldn't ever > use both. In the end, we're free to do anything we want, I just think it is > bad practice to mix things up like described above. In extreme cases, just > have a look at Windows, where anybody can install anything anywhere, we all > know what it ends up like :P What worries me about this is that you're making a clear distinction between "users" and "developers". I'm not convinced that is really consistent with the Arch Way, which I have always admired because it expects that the line between users and developers is blurry, and actively encourages users to experiment and cross over. The idea of needing to "switch" to ruby's (purpose-built) method of handling gems when a user wants to achieve "developer" status seems wrong to me. And for what? sudo pacman -S ruby-json sudo pacman -R ruby-json instead of: sudo gem install json sudo gem uninstall json It doesn't seem worth it to me. The commands can easily be documented in the wiki, and then the bar is lowered that tiny bit more for hacking something together in Ruby. Bear in mind that rubygems doesn't spread files all over the system, either. They're kept neatly tucked out of the way in /usr/lib/ruby, except for a few wrappers that end up in /usr/bin so that they're in the PATH. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 16:35:16 Maxime Gauduin wrote: > > For system-wide gems, I do "sudo gem install ". That works because > > I've restored > > /etc/gemrc so that it reads simply "gem:", instead of "gem: > > --user-install". I'm still not clear > > on why this configuration file is altered in the Arch package. I think > > it's because there's a > > feeling that system-wide gems should be handled by pacman, which I > > personally find weird. > > That is not a feeling, gemrc is removed on purpose so that you _don't_ run > "sudo gem". Your whole system is managed by pacman except for some dirs, > why wreak havok in it by using some other package manager? I'm exagerating > on purpose, I know rubygem does its job well and there shouldn't be > conflicts bewteen the two, but it just doesn't feel right. We're talking about two completely different domains that both happen to use the filesystem for storage. Ruby gems are not packages in the same sense that Firefox is a package. It's a different concept, and although I agree that Pacman could do an acceptable job of managing Ruby gems insofar as both systems bundle files for installation, it is not possible to map the two systems completely. They are built for different purposes, and have different semantics. > Yes, gem is easy to use, so is pacman. You can achieve the same results > with pacman-handled ruby packages given some effort on the maintainer's > part (apart maybe for the, imho unneeded, complexity of having multiple > versions of the same gem, but that is another story). To some extent, yes. You end up with a lowest-common-denominator situation. It's acceptable for casual use, I'm sure. > > When you start doing Ruby development, you quickly come to rely on > > Bundler, which relies > > on Rubygems. Throwing Pacman into the mix would cause a big mess, at > > least until you > > learn to use rbenv or something similar. > > As I mentioned above, you can easily reverse that statement. Why throw > Bundler and Rubygems in the mix when you have pacman? I personally think > that having pacman-managed dirs tinkered with by another package manager is > heresy :P I have no problem using one in "~" or any other dir that pacman > does not manage though, and as Rashif said, all in all it's just a matter > of options and preferences. Based on that paragraph, I'd be surprised if you had undertaken any serious development in Ruby. Many Rails developers work on Macs (not to mention other flavours of Linux), and Rubygems and Bundler are cross-platform tools. Relying on Pacman for Ruby development would render a project pointlessly platform-dependent. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 12:59:28 Maxime Gauduin wrote: > IMHO, the reason why you would choose to use rubygem over pacman depends of > how extensive a ruby user you are. I like to have gems handled by pacman, > but I only use a few of them and don't need to have several versions of the > same gem. Having them installed system-wise also makes them easily > available to all users. That being said, you can achieve the same with > rubygem by sharing a common ruby home between your users. As for the files > not handled by pacman, home dirs are not referenced anyway so having gems > in it really doesn't hurt. For system-wide gems, I do "sudo gem install ". That works because I've restored /etc/gemrc so that it reads simply "gem:", instead of "gem: --user-install". I'm still not clear on why this configuration file is altered in the Arch package. I think it's because there's a feeling that system-wide gems should be handled by pacman, which I personally find weird. I get that people may be afraid of using a second package manager, but Rubygems is incredibly easy to use, and handles gems much more effectively than can be achieved in pacman, because Rubygems is domain-specific. A quick command reference on the Ruby page on the Wiki should be enough. When you start doing Ruby development, you quickly come to rely on Bundler, which relies on Rubygems. Throwing Pacman into the mix would cause a big mess, at least until you learn to use rbenv or something similar. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 13:17:13 Magnus Therning wrote: > On Mon, Jan 13, 2014 at 11:45 AM, Simon Hanna wrote: > > Since ruby allready comes with a package manager (mentioned earlier), I > > never downloaded anything from the aur, but used rubygems instead. My > > question is, if we really need to have all these packages in the aur. > > Isn't > > it easier to manage everything with rubygems?? > > As someone who doesn't develop in Ruby at all, is it really true that > ruby comes with a package manager (as defined here: > http://en.wikipedia.org/wiki/Package_management_system)? In > particular, does it support > 1. removal of packages > 2. non-ruby dependencies * Yes, Rubygems is a package manager. * It is geared toward packaging ruby code and binary extensions. * It can remove packages entirely or clean out all but the latest version. * It can not handle non-ruby dependencies, except for those that can be compiled into a native ruby extension, which becomes part of the installed gem. * It wouldn't be a good choice for a language other than ruby. It is really quite domain- specific. Paul
Re: [arch-general] Ruby gem packages in Arch
On Monday 13 Jan 2014 11:38:57 Alfredo Palhares wrote: > I agree with you, some ruby-packages just are a royal pain in the arse to > maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I > still have some packages that use the old naming convention. > > But like you said the worst scenerio is to deal with multiple versions, like > one fact you need to update an gem, but packages that depend on it need an > older version of it, so now you have to have 2 versions of that gem. > > It can be done, we just need more man power to put quality packages. Forgive me: I'm a little unclear on why it's better to have the packages available via pacman? I do development in Rails and am personally perfectly happy to use rubygems (and rbenv, for larger projects) for gem management. I suppose it does mean there are files installed on the system that pacman can't identify, but personally I use rubygems enough that I have no problem handling the concept of two package managers that operate in different domains... I'm not trying to dismiss your effort, I'm just concerned that this seems a little like duplication. Paul
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Sunday 05 Jan 2014 23:03:23 Mark Lee wrote: > This all boils down to what does Arch consider a bug. If code that > cannot be compiled in parallel is a bug then Arch should make parallel > building the default (since these are bugs that upstream should fix). If > instead it is not a bug but is the intention of upstream developers, > then it shoudln't be enabled by default. Who is responsible for ensuring > parallel building works? It's worse than that: it's not just a bug, it's a randomly-occurring bug. It's something that users need to be aware of *before* they encounter it, because it will not produce a reliable error message that can be searched for, and may not even be descriptive. I think it makes more sense to suggest the option via the wiki, or in the makepkg.conf file, along with a warning about potential occasional breakage. This seems the most Arch-like solution to me: it's a safe default, but offers improved performance for users willing to take the time to poke around and understand better. Paul
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Friday 03 Jan 2014 16:26:27 Thomas Bächler wrote: > Error and inexperience can occur while learning. If you upload to the > AUR, I expect you to have polished and finished material, not your first > draft. > > There's enough places with kind people who will look at your PKGBUILD > and point out your mistakes. The AUR isn't one of those places. If these packages actually are "first drafts", then yeah, people are not actually taking their packages seriously, and maybe the AUR would benefit from a scratchbox area. However, my experience is that many people respond well when I point out the mistakes they've made. Many people are happy with "it works", and fail to see the purpose of going out of their way to ensure their work is "correct". Such people benefit from the input of those of us who for whom this comes more naturally. Bottom line: many people who own packages on the AUR simply want to install the software, with the minimum amount of effort, and thought it would be nice to share their hacked-together PKGBUILD with others to save them the trouble. If we want to enforce package correctness and good practice, we need more automation to flag those sorts of issues. Paul
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Friday 03 Jan 2014 15:49:27 Thomas Bächler wrote: > If you are not "experienced", you should think about your operating > system choice. We are not a kindergarten, we are a distribution with a > target audience of experienced and advanced users.x I reckon plenty of Arch users weren't used to customising or building packages before they came to Arch, and may not have done all that much building from source. That's not unreasonable. > If it were my choice, we would enforce high quality standards for the > AUR (which would likely force us to delete 90% of PKGBUILDs from it). Sounds like a barrel of laughs! > If you just want to "throw a piece of software on the AUR" without > checking the PKGBUILD for compliance with expected quality standards and > correctness, then fuck you. I will not stand by while we encourage > people to continue to produce low-quality bullshit and upload it to the AUR. So just to get this straight: if someone's going to become a packager, they need to learn how to do it *instantly*. There should be no margin for error and inexperience. Correct? Have you considered a career in education? :p Paul
Re: [arch-general] Default value of "j" in makeflags of makepkg.conf
On Friday 03 Jan 2014 15:33:05 Martti Kühne wrote: > Because I have a strong opinion about this. Also to prevent people > from running into this who are not that experienced in making things > work. If someone makes more than a few packages, they will have encountered makepkg.conf, to at least set their e-mail address. When I started using Arch, I think I discovered makepkg.conf and added the -j to makeflags pretty much on day one of experimenting with PKGBUILDs. But I think it comes down to this: 1) If someone knows that the -j flag exists, it won't take them long to figure out how to add it to makeflags, and then the responsibility is with them to ensure they know it can (rarely!) break some builds. 2) If the -j flag is added by default, builds may break unpredictably, and users will not know why. They may not be aware of -j, and may not make the connection to makepkg.conf at all. Option 1 seems a safer default to me. However, I think this should be properly documented in makepkg.conf: there should be an actual suggestion to add -j, along with a warning that in rare cases it may cause breakage. Just a single-line comment, possibly with a link to the wiki, would be enough. Paul
